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

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


Doug's SequenceLock requires that the data being read is volatile.

* <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
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Vitaly
  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

  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>
    >> current == value you've just read by .get() few lines ago.
    > Ahh, right.
    > For references, would .compareAndSet(null, null), also add in the
    > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120120/6b9c2885/attachment-0001.html>

More information about the Concurrency-interest mailing list