[concurrency-interest] Volatile and primitive arrays

Ben Manes ben_manes at yahoo.com
Mon Jun 16 03:31:48 EDT 2008

That was my impression too, and I'm over half-way through, but it gets better when you get passed the registers/locks chapters.  There are enough minor programming errors throughout the text, such as constructors not properly setting fields (e.g. Y(x) {x = x}) that its pretty evident that the code was not tested.  It would have been nice if the authors had written the code, with tests, and made it available.  But alas its pseudo-java, with an absolutely excellent presentation.

So far I've really enjoyed the chapter exercises.  I may ask the Dante's Inferno question (ch10, #123) during interviews for performance engineers, since its easy enough to write a naive implementation and provides a lot of good material for discussions.

----- Original Message ----
From: Jed Wesley-Smith <jed at atlassian.com>
To: Brian Goetz <brian at briangoetz.com>
Cc: concurrency-interest at cs.oswego.edu
Sent: Sunday, June 15, 2008 9:08:09 PM
Subject: Re: [concurrency-interest] Volatile and primitive arrays

After finally getting my copy and reading on the weekend, it seems that 
the whole book uses a kind of pseudo-code written in Java syntax that 
run on an idealised VM where the code is sequentially consistent (at 
least, no read-write re-orderings) and with immediate visibility 
effects. This is a useful device as far as it goes (in explaining their 
concepts) but can be quite frustrating for the casual observer (no, it 
must be final!). The fact that they also mix java.util.concurrent.* 
classes into the mix further muddies the waters. The fact that those 
specific examples misuse volatile must be an error as it doesn't appear 
to be repeated later (I haven't been through it with a fine toothed comb).

That said, I'm enjoying the book a lot.

Brian Goetz wrote:
> I noticed the same thing.  The code is wrong if you interpret it as Java code. 
>    You could argue that it is pseudo-code, but its really too close to Java to 
> make that argument effectively.  I've already got it scribbled down for my 
> next batch of errata that I'll send to Maurice.
> Tim Halloran 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080616/76e7308c/attachment.html 

More information about the Concurrency-interest mailing list