Slides for tomorrow night

[Boehm, Hans]

Thanks for putting this together.

I second Doug's comments.  A few more:

Silde 5: The font used for the code is hard to read, at least on my machine.  If it looks good on your machine, make sure you use it for the talk.

Slide 5 and 6:  I think this isn't quite accurate.  Generally reads and writes can't be moved across the lock because lock implementations are carefully designed to make them opaque to the compiler.  This prevents movement of reads and writes across them, even for user-space OS provided locks.  And there is generally no way for the user to roll his/her own since that's impossible without asm's or the like, and those can again be made opaque.  The problem is really that there is nothing to prevent the compiler from introducing additional reads and writes of globals, e.g. to promote them to a register in certain code sections.  That can be correct around calls to opaque functions, even when moving the read or write wouldn't be.

Note that this has nothing to do with system calls.  For example, I think Linux pthread_spin_{trylock, unlock} never make a system call.  And they're probably fine if you only use gcc to compile your code.

Slide 8: My impression is that even if both are volatile, the official pthreads position is that volatile has nothing to do with thread visibility, and therefore you get no gurantees.  (cf. http://www.talkaboutprogramming.com/group/comp.programming.threads/messages/41517.html )  And indeed the pthread standard is quite explicit that any race, even involving volatiles, gives you undefined semantics.  (I think it's unclear as to what constitutes a race, i.e. whether the race must exist for a sequentially consistent execution.  That's yet another problem that needs to be fixed.)

You might also mention the IA64 situation, where volatile actually has stronger semantics.  It argues both that there is a precedent, and that not everyone is happy with the current weak rules.  (I'm not sure what X86-64 did.  At least on Linux, it followed some IA64 precedents, but the rules seem to have been much more informally developed, and seem to be less well-specified.)

Slide 14:  I dislike overloadings of << which are completely unrelated to the original "much less than" or the C "left shift" meaning.  But I guess this group has already developed a tolerance for that ...  (The Java mm spec uses a single arrow with "hb" over it, which I greatly prefer, but is harder to typeset.  How about -hb> for now?)

Hans



> -----Original Message-----
> From: Doug Lea [mailto:dl at cs.oswego.edu]
> Sent: Monday, October 18, 2004 7:27 AM
> To: Andrei Alexandrescu
> Cc: Kevlin Henney; Maged Michael; Doug Lea; Boehm, Hans; Ben 
> Hutchings;
> pugh at cs.umd.edu
> Subject: Re: Slides for tomorrow night
> 
> 
> A few suggestions:
> 
> Slide 7: Kill bullet "Simple, efficient synchronization
> device". It is so simple that it is almost never a good idea :-)
> 
> For emphasis, I'd include one of Hans's examples to show low-level
> 
> Slide 9: Maybe add something explaining that a typical "volatile
> write" costs about half as much as a typical uncontended lock.
> 
> Slide 10: You might note that CAS stuff needs to be in a new std
> class.
> 
> Slide 12: Add disadvantages: Subject to livelock, high memory 
> contention,
> hard to control backoffs, ...
> 
>   (I like lock free algorithms a lot, but that's because I 
> know when not
>   to use them :-)
> 
> 
> Slide 15: I'm a little confused about the comments about "const" 
> Is the intent to mirror java "final fields"?
> 
> 
> -Doug
>