Sarita Adve wrote:
> To put another way, multithreaded Java
> programmers can't get around understanding happens-before, regardless of
> whether we choose strong or weak semantics - there's no way to correctly
> explain the semantics through barriers or roach motels.
Then I fear that there will be very few people who will actually be able to
use volatiles correctly and vis-a-vis there will be many misuses of
volatiles and many incorrect articles/talks/books describing volatiles. If
these things can't be expressed in simple terms via barriers and "roach
motels" then volatiles will be unusable to most people.
As a programmer, having being informed that the code I type in my editor
need not occur in the order in which I write it, I need tools to enforce
order where it is essential. To use volatiles I need to understand two
things: the effects on ordering and the effects on visibility. Roach motel
describes ordering constraints in a simple way that can easily be
communicated. Similarly the "barrier" effects of acquire and release
semantics.
If the programmer has to understand happens-before in detail, then I think
we have failed.
> The real issue is quite simply this: when determining whether a write-read
> conflicting synchronization edge is part of happens before, do we allow
> ourselves to use information about a total order on conflicting
> synchronization writes?
It may be simple to you and a few others, but as I've said before I cannot
understand what this means such that I can appreciate the difference in the
semantics with regard to actual pieces of code. I asked in response to
Bill's example whether the issue boiled down to whether two volatile writes
could be re-ordered but I received no response. I need to know what this
means to me as a potential implementor of lock-free algorithms utilising
volatiles.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:01 EDT