[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;
> l.lock();
>
> 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 
unlocked again.

I'm not sure this is a weakness in tryLock().  The user is making all 
kinds of faulty assumptions in this code.
-- 
- DML


More information about the Concurrency-interest mailing list