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

Szabolcs Ferenczi szabolcs.ferenczi at gmail.com
Tue Jun 23 16:57:57 EDT 2009


> I hadn't seen these "thread safety" annotations before.

Well, it all started as a newbee question and Concurrent Pascal, the
first concurrent class based language is usually not known by newbees.
It containes something very similar to "thread safety" annotations:
access rights. It really adds safety since it allows compiler checks
in concurrent programs.

Cheers,
Szabolcs

2009/6/23 Boehm, Hans <hans.boehm at hp.com>:
> 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.
>
> Hans
>
> ________________________________
> 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.
> --tim
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>



More information about the Concurrency-interest mailing list