Threads: first milestone completed

Doug Lea dl at cs.oswego.edu
Sat Oct 23 13:03:36 BST 2004


> - As you all well know fence instructions are very expensive and getting 
> more expensive with faster processors. So, it is crucial to define a model 
> that can offer performance-conscious programmers the ability to write code 
> that has *zero* fence overhead over hardware-mandated fence instructions. 
> That is, the model should allow programmers to write code that generates 
> no more fence instructions than those that have to be included in an 
> assembly implementation.

When considering this issue over the course of several years in Java,
we tried to balance the needs of "ordinary" vs "expert" concurrent
programmers.  We ended making the normal semantics of "volatile"
fairly heavy, but allowing somewhat finer control via operations on
Atomic classes. I still think this is the only sensible tactic. You
want, for example, double-checked locking to work if people declare
references as volatile, and only the read==acquire, write==release
semantics suffice for this. (I'm using acquire and release too
loosely, see the spec for details
http://www.cs.umd.edu/~pugh/java/memoryModel/).

The underlying motivation here is improving overall software quality.
Programmers without deep understanding of memory models (i.e., 99.999%
of them) should be able to write correct code by following a few
recipes. Experts may need to write ugly code to get exactly the
effects they want, but so long as there is SOME path for them to do
this, all is well.

Similarly, we also tried to stay away from specs that are too
closely tied to the quirks of processors -- the base model provides
underlying semantics, and we have  separate guides for programmers, as in:
  http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html
and compiler writers for common MPs, as in:
  http://gee.cs.oswego.edu/dl/jmm/cookbook.html

(Note: The C# memory model conflates these, in a way that leaves open
several semantics issues, and also seems challenging at best to
interpret when applied for example to DSM systems.)

In C++, you'd want even more fine-grained control than we provided in
Java for the Atomic classes. Hans and I have mentioned this a few
times, but we haven't nailed exactly which read and write operations
to support.  We should do this.


-Doug






More information about the cpp-threads mailing list