Slides for tomorrow night

[Andrei Alexandrescu]

> Slide 7: Kill bullet "Simple, efficient synchronization
> device". It is so simple that it is almost never a good idea :-)

I totally agree. It's hard to come with good examples. Here I have a 
little story to tell with a ticker that periodically looks at stock 
data, and a stream of events that periodically writes to the stock data. 
The two shouldn't wait for one another, and the stream should work 
without a hitch if the ticker is not displayed. In such a setting, 
synchronization based on ordering (as shown in the example) would make, 
I believe, sense.

> For emphasis, I'd include one of Hans's examples to show low-level

Unfinished sentence... I'd be interested to hear the rest. Which example 
do you have in mind?

> 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 :-)

Thanks, good points which I'll integrate. But I didn't think CAS-based 
programming is prone to livelocks... Maged?

Overall, I would like to keep lock-free as a part of the argument. 
Otherwise, people will look at classic locking and will say, hey, we 
only need to define two special functions (lock constructor and lock 
destructor) that ensure memory consistency, and we're home free without 
the memory barrier and volatile stuff.


Andrei