At 8:56 PM -0500 11/26/99, Doug Lea wrote:
>For the main examples, to get a standard read barrier, do:
>
> synchronized(new Object()) {
> localVar = field;
> }
>
>and a standard write barrier via
>
> synchronized(new Object()) {
> field = localVar;
> }
No, please don't go down this road; at least, not yet.
In order for removing memory barriers associated with useless locks a
legal optimization, synchronized(new Object()) { } _must_ be a no-op.
At 8:56 PM -0500 11/26/99, Doug Lea wrote:
> how about just doing the obvious, and
> creating:
>
> class java.lang.MemoryBarrier {
> public static native void loadStoreBarrier();
> public static native void loadLoadBarrier();
> public static native void storeLoadBarrier();
> public static native void storeStoreBarrier();
> }
I wouldn't like that solution either. For one thing, it would be very
different to derive a formal memory model in which removing memory
barriers associated with redundant synchronization was legal, but
which supported "naked" memory barrier calls. It would also make it
hard or impossible to define what a data race is.
Another reasons: if we supported these methods, Doug and 2-3 other
people might use them correctly. Thousands of people would use them
incorrectly. (Would people put in calls to all of the memory barriers
that might be needed, or just to the ones they know will be required
on the architecture they plan to run on)?
Doug seems worried that volatile will be expensive, but I'm not. On
Sparcs, all that is required is that after a write to a volatile
variable such that the next volatile memory operation might be a
read, a StoreLoad Membar is needed.
The guidelines I'm keeping in mind at the moment is that we should be
designing a memory model for the masses, not for experts like Doug.
I'm working on some stuff that will allow compiler optimization to do
things like synthesize CAS instructions. We can do this within the
simple memory model for the masses.
Bill
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:23 EDT