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

Boehm, Hans hans.boehm at hp.com
Thu Jan 19 19:58:42 EST 2012


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<mailto: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<mailto:raphfrk at gmail.com>>:
> On Thu, Jan 19, 2012 at 8:48 PM, Ruslan Cheremin <cheremin at gmail.com<mailto: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<mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto: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/20120120/c5d9b96c/attachment.html>


More information about the Concurrency-interest mailing list