> > Of course, we got a fair number of volatile fields in here as well, so
> > figuring out the exact number of memory barriers required by this code
> > is a little tricky. It is somewhat simplified by the fact that the CAS
> > probably acts as a memory barrier on most machines.
>
>on what machine does it do that??? certainly not on PowerPC. one of
>the big advantages of programming with atomic ops is that you avoid the
>need for memory barriers.
>
>it was also my impression from reading the arch manuals that it wasn't a
>barrier on Alpha or SPARC RMO.
My Oops. However, the algorithms given in Michaels paper don't work
on machines with a weak memory model, such as an Alpha. He tested his
programs on an SGI, which I believe is sequentially consistent, do it
doesn't come up in his tests.
>
>for instance
>
> class AtomicInteger implements AtomicOperation {
> private int x = 0;
>
> public synchronized set(int y) { x = y; }
>
> public synchronized fetchAndAdd(int y) { x += y; }
>
> public synchronized int value() { return x; }
> }
>
>the AtomicOperation interface is really a pragma that tells the compiler
>to convert this class to use atomic ops. since there is only one scalar
>single-word variable, and it is private, and all methods are
>synchronized, and there is no looping or blocking, the methods can be
>converted to use atomic ops. since the analysis is totally local, even
>a relatively dumb JIT could do it.
A big problem here is that an instance of AtomicInteger can be locked
using a synchronized block, which should block any of these
operations from occurring.
In order to do this type of transformation, you have to guarantee
that the object being locked isn't visible outside of the class.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT