[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Doug Lea dl at cs.oswego.edu
Mon Nov 28 15:34:04 EST 2011

On 11/28/11 14:23, Boehm, Hans wrote:
> There's another problem with tryLock()-like methods, which I pointed out in a
> 2007 PPoPP paper.  I think the current j.u.c.tryLock() is not correctly
> specified.  The problem is illustrated by the following badly designed code:
> Thread 1: x = 17; l.lock();
> Thread 2: while (l.tryLock()) l.unlock(); ... x ...  // x should be 17 here!
> A solution, more or less adopted by C++11, is to specify tryLock() as
> allowing spurious failures,

I think we are OK on this. The Lock spec defines tryLock in terms
of the lock being "available", which means different things
across different Lock implementations, and doesn't rule out
spurious false returns.

While I'm at it... Sorry to be too swamped to reply lately,
but here are a few quick comments on recent postings:

* I agree that store fences for object headers are normally
needed in constructors on ARM/POWER, and that they might as
well be piggybacked with those for final fields, but I don't
think implementations currently explicitly do so.

* I also agree that narrowly-targeted native STM support might
be worth  pursuing but not a high priority.

* I still don't know of a way to make AtomicReferenceFieldUpdaters
as fast as raw Unsafe. As long as there is any performance difference
at all, some people will use Unsafe.


More information about the Concurrency-interest mailing list