On Sunday July 8, 9:10am, Bill Pugh wrote:
> Actually, I didn't make the case strong enough. Making volatile
> read/write be full two directional memory barriers will also at least
> double the cost of volatile reads on x86 and Sparc, in addition to
> IA-64 and Alpha processors, as well as just about any other processor.
I can see that there is a cost issue. The question is whether trading
performance against programming model simplicity is the right trade to make.
On Sunday July 8, 11:33am, Bill Pugh wrote:
> One of my major questions is: what applications/idioms need full
> two-way memory barriers for volatiles.
Idioms that simply communicate values between threads can use the one-way
barriers being proposed: this covers the classic "stopping the applet
thread" example and the "Future object" example. I'm not sure if it will fix
the double-check idiom or whether that too needs some extra bits to make it
Idioms that in addition to data transfer require "coordination" with
monitors, need the two-way semantics. This includes the optimistic readers
transform and implementing forms of CAS at the Java level (as per Alex
Garthwaite's offline example).
This seems to cover the examples I have seen. Things like implementing
Dekkers algorithm seem to be okay with the one-way semantics, primarily
because reads/writes of the volatile flags seem to occur in sequence anyway.
Mind you I'm not 100% certain that some of those sequences couldn't
themselves be reordered - do we still have total ordering for all volatile
On Sunday July 8, 5:20pm, Miles Sabin wrote:
> I'm happy with the semantics, but I'm not too happy with the idiom.
> It's too obscure: I can see the dummy reads and writes being
> 'optimized' away by developers who don't understand what they're for.
> Couldn't we revisit Dougs suggestion of a magic class with methods
> along the lines of,
> public static void readBarrier();
> public static void writeBarrier();
I agree with Miles. If we do adopt the cheaper one-way semantics then we
should "formalise" the two-way semantics in a support class. This may simply
be by means of documenting a hypothetical class initially but I'm sure we
can push for a real class in Tiger (1.5) and beyond.
I'm still not convinced this is the right trade-off, because although we
would like to think that use of volatile will be restricted to the
"knowledgeable few" we know that everyone is going to use them when they
perceive they have a synchronization performance problem. The details of
using volatile correctly will rarely be transferred between people, rather,
as Joe Bowbeer alluded, people will just say "use a volatile and everything
will be alright".
Maybe we can prepare both versions of the spec (the two-way is just a
strengthening of the one-way) and let the "people" decide when we go out to
community review? Maybe by then we can demonstrate both the performance
issues and the programmability issues.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT