[concurrency-interest] Volatile and primitive arrays

[David Holmes]

Yes he's sure :) The only "happens-before" property that volatile has is as
follows: a volatile write happens-before a subsequent volatile read of the
value written.

If you only have reads you don't have happens-before.

Cheers,
David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Guy Korland
  Sent: Saturday, 31 May 2008 12:24 PM
  To: Tim Peierls
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Volatile and primitive arrays


  Are you sure? This will break the "Happens-before order" property that
volatile provides.

  Guy


  On Sat, May 31, 2008 at 5:18 AM, Tim Peierls <tim at peierls.net> wrote:

    The visibility effects of volatile only apply when you have a read of a
field following a write of that field. Successive reads of a field don't
have any special properties.

    --tim



    On Fri, May 30, 2008 at 10:05 PM, Guy Korland <gkorland at gmail.com>
wrote:

      Hi Tim

      If you really think about it, since java 5, it's not an error.
      Since all the author was trying to do is to promise that thread will
read a fresh value.

      When a thread call flag[j] it really access a volatile reference
"flag" which flashes the all memory since java 5 and then read the place in
the array which in fact was already refreshed.

      Guy


      >Thanks Tim, I'll send the authors an errata...they can decide what to
do.
      >On Fri, May 30, 2008 at 9:58 AM, Tim Peierls <tim at peierls.net> wrote:

      > I noticed that, too, but I figured the authors were skating
(sloppily)
      > around the unfortunate fact that you can't have arrays of volatiles.
They
      > should certainly have footnoted it as pseudo-code. They should have
just
      > used two volatiles, flag1 and flag2.
      >
      > --tim
      >
      > On Fri, May 30, 2008 at 9:44 AM, Tim Halloran <hallorant at gmail.com>
wrote:
      >
      >> On page 27 of Herlihy & Shavit's "The Art of Multiprocessor
Programming" I
      >> ran into this code which is a 2-thread solution for a Lock.  (I
don't think
      >> you need the book to understand my question.)
      >>
      >> public class Peterson implements Lock {
      >>     // thread-local index, 0 or 1
      >>     private volatile boolean[] flag = new boolean[2];
      >>     private volatile int victim;
      >>
      >>     public void lock() {
      >>         int i = ThreadID.get();
      >>         int j = 1 - i;
      >>         flag[i] = true; // I'm interested
      >>         victim = i; // You go first
      >>         while (flag[j] && victim == i) {
      >>             // wait
      >>         }
      >>     }
      >>
      >>     public void unlock() {
      >>         int i = ThreadID.get();
      >>         flag[i] = false;
      >>     }
      >> }
      >>
      >> The issue is the declaration of the boolean array "flag" (not the
lock
      >> algorithm).  The authors note (on page 25) that the fields need to
be
      >> volatile in Java to work, however, I don't think "flag" is working
the way
      >> they expect.  Am I wrong?
      >>
      >> First, I think "flag" should be declared "final" not "volatile" as
the
      >> field should never be mutated.
      >>
      >>     private final boolean[] flag = new boolean[2];
      >>
      >> Here, my confusion starts as I think this can't be fixed in Java.
I
      >> believe there is no way to indicate that the primitive elements of
an array
      >> are volatile (e.g., give them the memory model semantics the
authors
      >> desire).
      >>
      >> I was hoping someone here would know for sure.  I was going to let
the
      >> authors know--but wanted to check my facts :-)
      >>
      >> Best Regards,
      >> Tim Halloran
      >>
      >> _______________________________________________
      >> Concurrency-interest mailing list
      >> Concurrency-interest at altair.cs.oswego.edu
      >> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
      >>
      >>
      >


      _______________________________________________
      Concurrency-interest mailing list
      Concurrency-interest at altair.cs.oswego.edu
      http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080531/44a25275/attachment-0001.html