[concurrency-interest] Suggestion: .hardGet() foratomicvariables

David Holmes davidcholmes at aapt.net.au
Thu Jan 19 20:41:35 EST 2012


Hans,

A CAS is  a two-way "barrier" as per the j.u.c package javadoc:

compareAndSet and all other read-and-update operations such as
getAndIncrement have the memory effects of both reading and writing volatile
variables

This is not dependent on the CAS succeeding - which may seem a little
surprising but means the VM must insert any additional explicit fence
instructions around the native CAS, eg StoreLoad; cas; LoadStore|LoadLoad.

There should probably be in implementation note that a delta of zero can not
be used to optimize away the effect of the volatile write.

David
  -----Original Message-----
  From: Boehm, Hans [mailto:hans.boehm at hp.com]
  Sent: Friday, 20 January 2012 10:59 AM
  To: dholmes at ieee.org; Vitaly Davidovich; Ruslan Cheremin
  Cc: concurrency-interest at cs.oswego.edu
  Subject: RE: [concurrency-interest] Suggestion: .hardGet()
foratomicvariables


  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/20120120/27d6f391/attachment-0001.html>


More information about the Concurrency-interest mailing list