Josh Bloch wrote:
> It's sheer lunacy to even think seriously about a model
> that breaks a simple "single check" idiom applied to integers.
> It's wildly counterintuitive.
Yes it is wildly counter-intuitive but then everything about MP memory
models is counter-intuitive. If there is any 'lunacy' in this it is the
fact that MP systems are allowed to do such things - given that they are,
then we have to deal with it.
The single-check idiom is the last in a long line of non-intuitive examples
that can produce surprising results when shared variables are accessed by
multiple threads without synchronisation. I grant that it is the most
non-intuitive of all the examples but that just makes it harder to see for
even the "experts". It reinforces the notion that there is no safe way to
share variables without some form of synchronisation.
> All it does is to ensure that Joe Programmer (not to be
> confused with Joe Bowbeer) will rarely, if ever, write a correct,
non-trivial
> multithreaded program.
If Joe Programmer follows the concurrent programming mantra of always using
synchronisation then they have no problems whatsoever. They only run into
problems when trying to get rid of synchronisation that they think
unnecessary due to flawed reasoning about the way MP systems work - in
short when Joe Programmer tries to program outside the box.
The problem we have at the moment is that the box is ill-defined. The box
presented by Ch17 has jagged edges and holes in it. We need a new box that
makes it easy to program correct concurrent programs (wrt. memory models)
but which doesn't impose too great a cost in terms of implementation.
I don't think we can define a box that allows the single-check idiom to
work without also making a lot of suspect idioms also work and I don't
think that would be a good thing to do. I do think we can define a workable
box that makes it easy for the programmer to keep within the box and which
also provides the implementation with a reasonable chance of efficiently
implementing the box. The key features of this box have already been
mentioned at different times in this mailing list and I think that by
putting them together we can get a workable solution. I'll describe this
box in a separate email - sorry for the suspense :)
The danger in this whole process is that the longer we discuss a new Ch17
the fewer our options will become. More and more "broken" code is being
written everyday and it will be difficult to identify when we have a
reached a point where it becomes untenable to allow Ch17 to be defined in
such a way that it reinforces the brokenness of that code. Perhaps we are
already beyond that point. When that happens the only answer will be
sequential consistency and tough-luck to those writing VM's for MP's with
relaxed memory models - a true cynic might suggest that this could even be
seen as a hardware marketing strategy ;-)
Cheers,
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT