Use of synchronized methods in components

[Cantor, Scott]

On 5/6/14, 3:16 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Are we suggesting that this be removed as and when we see it, or as a
>conscious effort?

The latter, I think this rises to the level of importance as to make that
worth doing. I don't think this is an area to leave inconsistent.

>I would also add that I have never understood what the @Threadsafe means
>when applied to a class.  I am not a neophyte with asynchronous systems,
>but
>I cannot really understand what it is meant to indicate - or rather I can
>think of too many thinks that it could mean.  Do we believe that this adds
>any value and of not can it go?

For me it means that a caller has absolutely no considerations about how
it uses an object across threads and if it wants to spin up multiple
threads and hammer all over it, it can do that safely with no extra care.
If you have explicit locking, that's not threadsafe, it's explicitly not
safe.

Java synchronized methods are implicit locks, so the caller doesn't have
to be aware of them other than for performance reasons, so that's still
thread-safe potentially.

I created ThreadsafeAfterInit to apply that same logic to objects that
only reach that state after they are initialized, which is a common case
we have.

The StorageService is an example of thread safety. It explicitly removes
all notions of locking from the interface, though it does expose
contention with versioning (but it doesn't presume to know that a version
conflict is unsafe, that's part of the API).

-- Scott