> People don't use "synchronized" properly as it is; I shudder to think what
> they'd do with an explicit memory barrier.
Just so this isn't take out of context. The discussions concerning explicit
memory barrier instructions were looking at ways, for example, of allowing
sophisticated concurrent data structures to be written in Java in a
lock-free/wait-free manner.
I think the general outcome of that discussion was that appropriate
semantics on "volatile" and "final" variables should obviate the need for
these - though at the expense of making "volatile" semantics more
far-reaching than at present.
A related suggestion was to allow, for example, "synchronized(null){...}" to
be reduced to only the memory barriers needed to effect the memory-model
semantics on that platform. This is equivalent to doing "synchronized(new
Object()){...}" but without the wasted effort. However this wasn't looked
upon favourably by those who want to remove "redundant" synchronisation
completely.
Within the context of those discussions any ability to move code across the
"barrier" would have completely broken the whole point of having the
constructs. Given that these "barriers" were simply representations of
synchronized blocks, it follows that synchronized blocks would exhibit the
same code motion prohibition properties.
I agree with Bill that correctly synchronized code - by which we mean code
that uses synchronized blocks to access shared variables - would not be
affected by the suggested code motions. If volatile/final variables get the
extended semantics that have been discussed, then the rules regarding code
motion around final/volatile accesses would also need to be defined.
Hopefully after all that we will be in a position where we can safely define
highly concurrent and efficient data structures.
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:26 EDT