[concurrency-interest] AtomicReference weakCompareAndSet"Mayfailspuriously"?

David Holmes dcholmes at optusnet.com.au
Sun May 28 22:10:21 EDT 2006


No, weakCompareAndSet does not force a "memory barrier" to happen.

The "issue" as now being discussed is how to describe weakCompareAndSets
lack of memory synchronization effects.

Cheers,
David Holmes

> -----Original Message-----
> From: Giuliano Mega [mailto:giuliano.mega at gmail.com]
> Sent: Monday, 29 May 2006 12:08 PM
> To: dholmes at ieee.org
> Cc: Bill Pugh; concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] AtomicReference
> weakCompareAndSet"Mayfailspuriously"?
>
>
> I am utterly confused, as always. :-)
> weakCompareAndSet does force a memory barrier to happen, right? The
> issue is just with reordering within a single thread?
>
> On 5/28/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> > 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
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
>
> --
> Giuliano Mega <giuliano at ime.usp.br>



More information about the Concurrency-interest mailing list