[concurrency-interest] [Javamemorymodel-discussion] Fences, AtomicXFieldUpdater enhancements, and @Racy annotations

Boehm, Hans hans.boehm at hp.com
Mon Jan 26 17:46:26 EST 2009


> -----Original Message-----
> From: javamemorymodel-discussion-bounces at cs.umd.edu 
> [mailto:javamemorymodel-discussion-bounces at cs.umd.edu] On 
> Behalf Of Paul E. McKenney
> Sent: Monday, January 26, 2009 6:31 AM
> To: Doug Lea
> Cc: Concurrency-interest at cs.oswego.edu; 
> javamemorymodel-discussion at cs.umd.edu
> Subject: Re: [Javamemorymodel-discussion] Fences, 
> AtomicXFieldUpdater enhancements, and @Racy annotations
> On Fri, Jan 16, 2009 at 08:43:12AM -0500, Doug Lea wrote:
> > [This one is equally on java.util.concurrent and JMM 
> issues, so please 
> > be tolerant of cross-post duplication.]
> > 
> > First, I'm getting more confident that the specs for Fence 
> API are in 
> > the right ballpark, although still need a bit more precision in the 
> > discussion of "scopes".  (If anyone want to help, please 
> do!) See the 
> > updated draft 
> > 
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atom
> > ic/Fences.html
> Does this support per-thread counters, which do not need any 
> particular ordering semantics, but which must avoid 
> load/store "tearing"?  I could interpret the earlier 
> discussion about Java's storage guarantees as covering this, 
> but thought I should ask explicitly.  I don't see anything in 
> the proposal that supports this sort of thing.
> (In per-thread counters, each thread adds to its own counter, 
> and a thread needing to access the count sums the per-thread 
> counters.)
> 						Thanx, Paul
I think those largely represent an orthogonal issue.  The answer depends on how approximate an answer you're happy with.  Ordinary Java non-volatile variables arguably work, so long as they are of type int, not long (or you do atomic replacement of pointers to them instead).  Only longs may exhibit "tearing".  However you don't get cache-coherence on individual per-thread counters.  Thus thread T2 may still observe thread T1s counter running backwards, but probably only by a little.  (This is a feature, not a bug.  Since, unlike in C++, these are ordinary variables, not weakly oprdered atomics, the optimization cost of preventing this is large, at least in the general case, since it's hard to tell when two read accesses alias.  This sort of "cache coherence" was required in the original Java memory model, but widely ignored.  That was a major factor in convincing Bill and Jeremy to revisit the issue.)


More information about the Concurrency-interest mailing list