[concurrency-interest] Synchronization blocks, locks and reorderings

David Holmes dcholmes at optusnet.com.au
Tue Jan 22 23:36:02 EST 2008


Hi Unmesh,

Ans #1: The write to x can move into the synchronized block, but it can't
move past it. In the memory model this is informally known as the "Roach
Motel" property - "you can move in but you can't move out". I don't recall
what formal rule defines this property; it might be a consequence of
maintaining "program order".

Ans #2: writer() holds the lock when the unlock occurs therefore the unlock
must happen before any subsequent lock by another thread - by the mutual
exclusion properties of locks. Now reader() could get the lock before
writer() but that wasn't the scenario being discussed. In general you have
to be careful about the logical notion of "happens before" and the
memory-model happens-before relationship.

Hope this clarifies things somewhat.

Cheers,
David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Unmesh joshi
  Sent: Wednesday, 23 January 2008 2:01 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] Synchronization blocks, locks and
reorderings


  Hi,

  I was reading http://today.java.net/pub/a/today/2004/04/13/JSR133.html.
Discussing reordering there,

  class Reordering {
    int x = 0, y = 0;
    Object l = new Object();

    public void writer() {
      x = 1;
      synchronized (l) {
        y = 2;
      }
    }

    public void reader() {
      synchronized (l) {
        int r1 = y;
        int r2 = x;
      }
    }
  }

  In the happens-before discussion it is stated that,

  "A thread calling reader() will now see the values of x and y placed there
by the thread calling writer(). The writer() method contains four actions --
write to x, lock l, write to y, and unlock l. By the program order rule, the
writes to x and y happen before the unlock of l. Similarly, the reader()
method contains four actions -- lock l, read x, read y, and unlock l, and
again by the program order rule the reads of x and y happen after the lock
operation. Since by the monitor rule, the unlock operation in writer()
happens before the lock operation in reader(), we can see (by transitivity)
that the writes to x and y in writer() happen before the reads of x and y in
reader(), and therefore the correct values are visible to the thread calling
reader()."

  I am little confused here,
  1. Because variable x is never read in synchronized block of writer, it
isn't compiler free to reorder read to x after write to y? Or there are no
reordering allowed around synchronization blocks?

  2. In the discussion, its stated that "the unlock operation in writer()
happens before the lock operation in reader()". How can this be guaranteed?
It can very well be exactly opposite, right?

  Thanks,
  Unmesh


----------------------------------------------------------------------------
--
  Post free auto ads on Yello Classifieds now! Try it now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080123/53685f8c/attachment.html 


More information about the Concurrency-interest mailing list