[concurrency-interest] AtomicReference weakCompareAndSet"Mayfailspuriously"?

David Holmes dcholmes at optusnet.com.au
Sun May 28 20:58:15 EDT 2006


Bill,

I understand the example you gave but I don't understand how you are
describing this.

To say something has volatile semantics but doesn't create a happens-before
edge seems to me to say nothing - ie volatile without happens-before ==
empty-set.

So while I understand v.weakCompareSet only establishes ordering of v with
respect to itself, I don't see how describing it as "volatile without
happens-before" communicates anything that would convey the way it operates
to the programmer.

Cheers,
David

> -----Original Message-----
> From: Bill Pugh [mailto:pugh at cs.umd.edu]
> Sent: Monday, 29 May 2006 10:51 AM
> To: dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] AtomicReference
> weakCompareAndSet"Mayfailspuriously"?
>
>
> > But isn't that all just a long-winded way of saything that it creates
> > happens-before edges?
>
> Nope.
>
> > Otherwise, what on earth does "creates happens-before edges" mean?
>
>
> Say we have:
>
> initially, x = 0 and v = AtomicInteger(0);
>
>
> Thread 1:
> x = 1
> while (!v.weakCompareAndSwap(0,1));
>
> Thread 2:
> while (v.get() == 0);
> r1 = x
>
> If thread 1 terminates, then because the actions on the atomic
> integer are synchronization
> actions,  thread 2 is guaranteed to see the update to v and
> terminate. However, no happens-before
> order is established between the weakCompareAndSwap in thread 1 and
> the get in thread 2.
> Thus, we don't have a happens-before order between the write to x and
> the read of x. Thus,
> this program is incorrectly synchronized and the read of x can see
> either 0 or 1.
>
>
> Bill



More information about the Concurrency-interest mailing list