[concurrency-interest] Thread-safety annotations (was RE: concurrency newbie question)

Boehm, Hans hans.boehm at hp.com
Tue Jun 23 15:02:47 EDT 2009

I hadn't seen these "thread safety" annotations before.  It seems to me that they actually fail to cover the most important part of the space, namely classes that

a) permit read sharing without synchronization,

b) permit different class instances to be accessed concurrently without synchronization, but

c) require synchronization if the same instance is being accessed by multiple threads and one of the accesses is a write.

Such classes effectively behave like, for example, a built-in Java long or double.  (And they behave like a built-in Java int that is being accessed without data races, as it should be 99.9% of the time.)  I think this should be the default design point for most classes that are not specifically concurrency-related; instances should behave like built-in data types.  It is basically how the newer Java collections like ArrayList behave.  It is explicitly the default for the C++ standard library.

It is easily possible to build classes that are not safe for concurrent read accesses  (e.g. lists that are reorganized on a read access, or splay trees) or that are not safe for concurrent access of distinct instances (e.g. if components of the objects are allocated using a shared custom allocator that doesn't synchronize), so I think these distinctions are important.


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Tim Peierls
Sent: Tuesday, June 23, 2009 6:41 AM
To: Chris Kessel
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] concurrency newbie question

Excellent advice -- not silly at all!  A real guru would have included this broader context from the start. ;-)

Minor point: For classes that must be confined to a single thread, rather than (only) putting a prose description like "thread contained" in the javadoc comments, consider in addition annotating such classes with @NotThreadSafe (http://jcip.net/annotations/doc/net/jcip/annotations/NotThreadSafe.html).

The only way @NotThreadSafe classes can be used correctly is through "serial thread confinement", i.e., confinement of an object to a single thread at a time with any hand-off of the object between threads restricted to happens-before relationships such as those described in http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility. (Serial thread confinement trivially includes simple confinement of an object to a single thread for the lifetime of the object.)

Incidentally, there is no JCiP annotation for "effectively immutable" classes, in which all mutative operations happen-before the object is published and multiple threads may perform read-only access after (safe) publication. Maybe there should be one.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090623/1caf8f01/attachment.html>

More information about the Concurrency-interest mailing list