[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe
David M. Lloyd
david.lloyd at redhat.com
Mon Nov 28 14:49:17 EST 2011
On 11/28/2011 01:23 PM, 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;
> Thread 2:
> while (l.tryLock()) l.unlock();
> ... x ... // x should be 17 here!
> Effectively this inverts the sense of the lock. Thread 2 can only proceed after thread 1 acquires the lock.
> The problem is that:
> - There are no potentially concurrent accesses to x in a sequentially consistent execution of this code, and hence there should be no data races
> - The Java memory model does not in fact guarantee that x is 17 in thread 2, because there is a data race by Java memory model definitions. This race is too hard to explain.
> - In order to ensure that x is actually 17, we would need to prevent reordering of the two lines of thread 1. This is expensive on something like PowerPC, and doesn't benefit well-written code.
I'd say that an even more basic problem is that if thread 1 locked and
unlocked quickly enough, and the scheduling fell out just right, thread
2 would never even notice that thread 1 took the lock if it was
unscheduled after its unlock and not rescheduled until after thread 1
I'm not sure this is a weakness in tryLock(). The user is making all
kinds of faulty assumptions in this code.
More information about the Concurrency-interest