[concurrency-interest] Fwd: Synchronization blocks, locks and reorderings

David Holmes dcholmes at optusnet.com.au
Wed Jan 23 20:49:17 EST 2008


I believe the article was intending to refer to the simple case where
execution of writer() in one thread completes before execution of reader()
in another. It doesn't discuss the possibilities if writer() and reader()
are interleaved.

David Holmes
  -----Original Message-----
  From: Szabolcs Ferenczi [mailto:szabolcs.ferenczi at gmail.com]
  Sent: Thursday, 24 January 2008 11:41 AM
  To: dholmes at ieee.org
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Fwd: Synchronization blocks, locks and
reorderings


  On 24/01/2008, David Holmes <dcholmes at optusnet.com.au > wrote:
    > the somewhat more interesting scenario is this:
    >
    > time writer()        reader()
    > ---- --------        --------
    > t1                   lock l
    > t2                   read y
    > t3   write to x
    > t4                   read x
    > t5                   unlock l
    > t6   lock l
    > t7   write to y
    > t8   unlock l
    >
    > Now what value of x will the reader read? According to the
happens-before
    stuff, value 0 will be > read from x despite that x has actually value 1
    already.

    No, the absence of a happens-before ordering between the read of x at t4
and
    write of x at t3 means that the read can return either 1 or 0

  Well, I agree with you and I also said that the code is not correct from
the concurrency point of view. However, you should check it with the author
of http://today.java.net/pub/a/today/2004/04/13/JSR133.html  who contradicts
you.

  Best Regards,
  Szabolcs


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080124/3c262aef/attachment.html 


More information about the Concurrency-interest mailing list