[concurrency-interest] Suggestion: .hardGet() for atomicvariables

Vitaly Davidovich vitalyd at gmail.com
Thu Jan 19 20:15:38 EST 2012


OK maybe I'm looking at this too x86-centric but under which architectures
would spinning on a seqlock not be enough? That is, why does the data you
read inside the loop need to be volatile, meaning you can't assume that the
spinning CAS won't provide the barrier? Intuitively, even though the CAS
loop reads unrelated memory to the body of the loop, I think it's
reasonable to assume that it provides an acquire fence, at least for a
successful CAS.  Granted that's an assumption but I'm curious under what
circumstances that wouldn't be the right thing to do.

Honestly, I'm really starting to think that the Fences API that Doug
proposed is the right way to go, similar to C++11x atomics - this would
allow explicit intent rather than mentally reconciling the JMM with actual
hardware.

Vitaly

Sent from my phone
On Jan 19, 2012 8:00 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:

>  Yes.   It does require volatile, as it should.****
>
> ** **
>
> Getting back to the earlier topic, I’m not at all convinced that a failed
> CAS behaves like a volatile write according to the Java memory model.
> There is no write that can synchronize with anything.  It probably does
> hold on X86.****
>
> ** **
>
> By my reading, getAndAdd(0) is required to write, and hence does the right
> thing.  If an implementation optimizes it to a volatile load, it’s wrong.
> If it uses a CAS loop, that’s fine, since the last one should succeed.****
>
> ** **
>
> Hans****
>
> ** **
>
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *David Holmes
> *Sent:* Thursday, January 19, 2012 4:20 PM
> *To:* Vitaly Davidovich; Ruslan Cheremin
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] Suggestion: .hardGet() for
> atomicvariables****
>
> ** **
>
> Vitaly,****
>
>  ****
>
> Doug's SequenceLock requires that the data being read is volatile.****
>
>  ****
>
> David****
>
> -------****
>
> * <p> Methods {@code awaitAvailability} and {@code getSequence} can****
>
>  * be used together to define (partially) optimistic read-only methods****
>
>  * that are usually more efficient than ReadWriteLocks when they****
>
>  * apply.  These methods should in general be structured as loops that****
>
>  * await lock availability, then read {@code volatile} fields into****
>
>  * local variables (and may further read other values derived from****
>
>  * these, for example the {@code length} of a {@code volatile} array),****
>
>  * and retry if the sequence number changed while doing so.****
>
>  -----Original Message-----
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of *Vitaly
> Davidovich
> *Sent:* Friday, 20 January 2012 7:42 AM
> *To:* Ruslan Cheremin
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] Suggestion: .hardGet() for
> atomicvariables****
>
> Failed cas won't write anything to cache (afterall you didn't modify
> anything).  However, it does achieve same memory fencing/ordering as a
> successful cas.  On x86/64 that's because the cmpxchg instruction is
> prefixed with LOCK, which by itself makes the instruction serializing
> irrespective of whether the cmpxchg succeeds.****
>
> Also, small addendum - processor doesn't always issue a RFO (request for
> ownership) before writing - if the cache line is in exclusive state in the
> writing processor, it doesn't need to do that.****
>
> Also Doug Lea has a version of seqlock in his CVS repo for jsr166e - you
> can take a look at it for details.  I'll tell you that there is no funny
> business there with dummy cas operations - he trusts volatile reads :).***
> *
>
> Sent from my phone****
>
> On Jan 19, 2012 4:05 PM, "Ruslan Cheremin" <cheremin at gmail.com> wrote:****
>
> I think, it depends on what you name "write". Failed CAS will be "like
> write" in sense of cache coherence traffic -- at least AFAIK -- it
> will request cache line to be in M state (read-for-update), so if
> cache line was in some other core's cache -- it will be invalidated.
> But failed CAS does not really update cache line value, so it seems
> like writeback to main memory not needed. I do not know, does current
> CPUs actually optimize this writeback.
>
> 2012/1/20 Raph Frank <raphfrk at gmail.com>:
> > On Thu, Jan 19, 2012 at 8:48 PM, Ruslan Cheremin <cheremin at gmail.com>
> wrote:
> >> current == value you've just read by .get() few lines ago.
> >
> > Ahh, right.
> >
> > For references, would .compareAndSet(null, null), also add in the
> syncing?
> >
> > Does a compare and set that fails to update count as a write, or just a
> read?
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> 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/20120119/3b045eff/attachment-0001.html>


More information about the Concurrency-interest mailing list