[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 28 21:48:42 EST 2011


Yes I realized that I misread the snippet right after I sent the email -
thanks though :).

However doing a tryLock will entail reading a volatile that was set during
lock, so shouldn't that provide the HB? Granted I'm talking about a
specific impl in the JDK.

I don't see how roach motel applies here since the lock() writes a volatile
and prior stores can't reorder with it (subsequent ones can move in though).
On Nov 28, 2011 9:39 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:

> **
> Vitaly,
>
> Thread 2 only reads x if the lock is not available, which means thread 1
> must have locked it, which occurs after setting x=17.
>
> However in terms of happens-before, there is no HB edge here so no
> guarantee of x being 17 AFAICS. Thread 2 has to acquire the lock after
> thread 1 to get a HB edge that guarantees x == 17. Further, roach-motel
> tells us that x=17 could be reordered with the lock() anyway.
>
> David
>
> -----Original Message-----
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of *Vitaly
> Davidovich
> *Sent:* Tuesday, 29 November 2011 12:30 PM
> *To:* Boehm, Hans
> *Cc:* Doug Lea; concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] AtomicReferenceFieldUpdater vs
> Unsafe
>
> Hi Hans,
>
> In your example why do you say that x should be 17 (or rather, why would
> someone assume that)? If thread one writes to x but gets descheduled before
> locking, then clearly thread 2 is not guaranteed to read 17; how is this
> different from if instead of using a lock, a volatile y was used?
>
> If thread 1 did lock before tryLock in thread 2 then the store to a
> volatile inside lock and a read of that volatile in tryLock should be
> sufficient to create the happens-before edge.
>
> I must be missing your point though.
>
> Thanks
> On Nov 28, 2011 8:23 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:
>
>> > From: Doug Lea
>> >
>> > 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.
>> That interpretation sounds good to me.  It does mean that a lock that was
>> constructed before the tryLock call and has never been accessed by anything
>> else might not be "available".
>>
>> Hans
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111128/e6a5d844/attachment-0001.html>


More information about the Concurrency-interest mailing list