Bill Pugh wrote,
> At 1:09 PM +1000 6/29/01, David Holmes wrote:
> > If volatiles are to be useful as flags in wait-free/non-blocking
> > algorithms then it seems to me that ordering is critical and so
> > volatile accesses should act as code motion barriers in both
> > directions.
>
> As I mentioned previously, you can get this semantics by adding a
> dummy volatile write before each volatile read, and a dummy volatile
> read after each volatile write (so long as the dummy volatile is
> shared). However, adding these semantics in general will make
> volatile more expensive, and is only needed/useful in rare
> circumstances.
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();
Given the new semanitics these could be trivial convenience functions
performing the dummy reads/writes (so baseline implementation cost is
close to zero) but presumably invocations could be special-cased by
JITs.
And I guess if we had such a magic class we might also help ourselves
to compareAndSwap(), doubleCompareAndSwap() etc. ...
Cheers,
Miles
-- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK msabin@interx.com http://www.interx.com/------------------------------- 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