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

Ruslan Cheremin cheremin at gmail.com
Fri Jan 20 06:10:08 EST 2012


2012/1/20 Boehm, Hans <hans.boehm at hp.com>:
> 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.


But, back to the topic, _failed_ CAS in this case means "optimistic
approach failed" anyway. Look, your "optimistic read" will be:

long seq = sequence.get();
...some reading...
if( !sequence.CAS(seq, seq) ){
   //...approach failed -> retry
}

So, from my point of view, if CAS failed -- we shouldn't actually care
about it's ordering semantic (although it was interesting to know --
thanks, David -- what ordering does not depend on success/fail). If
CAS succeeded -- it does required guarantee anyway. Am I wrong
somewhere here?


> 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



More information about the Concurrency-interest mailing list