I'm a PhD student working on synchronisation in OO systems (not in terms of
the current level of discussions however). For the past 2-1/2 years I've
been involved in teaching people about Java's concurrency model and work a
lot with Doug Lea. Most of the contributors to the list so far, know me :-)
I've been debating the JMM with people for a long, long time now and have a
number of ongoing disagreements with some people. I first got involved in
this issue after in-depth discussion of the incorrectness of the
"double-check locking idiom" on MP systems, that took part in
comp.programming.threads - with Dave Butenhof telling people the way things
are. That began my education in MP memory consistency models.
I am a firm believer that all access to mutable shared data must be
protected using synchronisation - "use the mutex Luke". However I've been
educated on the subtleties of some of the issues and agree that data races
must not be allowed to break the language rules. Hence we need rules that
ensure that constructed objects must be seen once the reference to them is
seen. For some of the other idioms I'm less convinced that they should be
made to work.
I tend to play "devil's advocate" in these discussions and have been most
concerned about the performance implications of some of the proposed fixes
on modern architectures. The fact that Mark Hill thinks SC is a good idea
for future MP's is totally irrelevant to reality as it stands. We have to
deal the systems that are being produced today and tomorrow.
Bill Pugh wrote:
> As I mentioned before, I think the Sparc RMO MM is OK. I haven't
> found anything yet in the Intel Merced spec that looks like a formal
> memory model.
My take with IA-64 architecture is that they don't intend giving a formal
memory model, rather they define a set of instructions with various memory
ordering/visibility characteristics. If you don't use those instructions to
get the required properties then the system is allowed to do pretty much
anything it likes.
I'll reiterate Doug Lea's comments that it is good to see that someone like
Bill Pugh has decided to champion the JMM cause. The lack of action over
the past two years has been very disappointing. Thanks Bill.
Department of Computing Phone: +61 2 9850 6343
Division of Information & FAX: +61 2 9850 9529
Communication Sciences http://www.mri.mq.edu.au/~dholmes
Sydney, NSW 2109, Australia
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email firstname.lastname@example.org and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:13 EDT