>
> At 08:41 AM 8/04/2004 -0400, Bill Pugh wrote:
> >I'll admit that I am conflicted with regard to the strong vs. weak
> >interpretation. If we had really worked this out 5 months
> ago, I'd be much
> >more open to considering a change.
> >
> >The problem is that the strong interpretation has been
> documented in both
> >the community review document and the public review
> document. There have
> >also been previous postings in which coding idioms where
> recommended that
> >only work under the strong interpretation (for the
> optimistic readers
> >pattern, which deliberating uses data races and detects and
> recovers when
> >a data race occurs).
>
Inspired by Sylvia's persistence, I went back to check on what had actually
been said about the optimistic readers idiom. The only message I found from
Bill on this issue is repeated below, which explicitly states that Bill does
not see the need for supporting such an idiom and implies that Bill is
already considering ways to break Rob's solution.
Please point me to a message that states that the optimistic readers idiom
will be supported. If there is no such message, then it further weakens
whatever little case there is for strong volatiles.
Sarita
From: Bill Pugh (pugh@cs.umd.edu)
Date: Tue Oct 31 2000 - 00:13:26 EST
The "Optimistic Read Idiom" is incorrectly synchronized code.
The "happens-before" relationships induced by by accesses to volatile
variables and locks do not impose an ordering constraint between all
conflicting accesses.
I see no need to support the "Optimistic Read Idiom", any more than I
see a need to support "Double-checked locking".
Under my semantics, as Rob observed, the write to a and b can be done
presciently, which means that the "Optimistic Read Idiom" will not
work.
Rob's trick, of inserting a read of v, would work under my existing
semantics. But I've already been considering ways of allowing
prescient writes to be moved ahead of volatile reads and locks who's
matching write/unlock is the same thread.
My interest is in having a simple model that is easy to explain. I
don't want the system to support any ugly hacks that would be
erroneously used 95% of the time.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:04 EDT