> 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.
based on my experience with programming MPs (as opposed to multithreaded
UPs), i would contend that any language that exposes a weak memory model
should also export access to atomic operations. they're incredibly
useful for writing sophisticated concurrent algorithms (in my case, a
concurrent GC).
the concensus certainly seems to be that anyone who understands and
makes use of a weak memory model is a sophisticated programmer. when it
comes to multiprocessors, java hides the good, but exposes the bad and
the ugly.
> I've been thinking about how a compiler could recognize that a
> synchronization lock could be replaced with a CAS instruction. I think
> the following code will do work for the Queue example.
of course you can't do that with the current memory semantics because of
the crazy "unlock is a global barrier" policy. but assuming that was
fixed....
why not just guarantee that the compiler will recognize a "load with
reservation/store conditional" idiom, and synthesize atomic ops for the
programmer, who can then use them to build sophisticated things like
wait-free queues?
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.
david
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT