[concurrency-interest] Clarification on jsr166e SequenceLock

Ashwin Jayaprakash ashwin.jayaprakash at gmail.com
Fri Jul 22 17:22:01 EDT 2011


I tried reading the doc on
http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/SequenceLock.htmlbut
I'm still not clear on what purpose this serves.

Why does the distanceFromOriginV1 method check for seq again after awaiting?
Is this supposed to demonstrate a "lock-less read of multiple volatile
fields" like a "read-committed" transaction?

If you do not have the do-while loop wouldn't it still be safe to read x and
y after awaiting only once? Or would that result in a case where x gets read
and by the time y gets read the next lock holder changes both x and y thus
resulting in an old currentX and a newer currentY?

I'm just wondering if the example/doc/feature is obvious enough for us
ordinary users to use properly :)

 double distanceFromOriginV1() { // A read-only method
      double currentX, currentY;
      long seq;
      do {
          seq = sl.awaitAvailability();
          currentX = x;
          currentY = y;
      } while (sl.getSequence() != seq); // retry if sequence changed
      return Math.sqrt(currentX * currentX + currentY * currentY);
  }



Ashwin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110722/26e0ea80/attachment.html>


More information about the Concurrency-interest mailing list