Slides for tomorrow night

[Boehm, Hans]

The argument I usually make is that you want to use lock-based techniques
for 98% of your code, but the other 2% maybe what determines much
of the performance of your program.

Library implementers will understand that.  In particular, I think
C++ basic_string implementations which reference count (a bad idea,
in my personal and controversial opinion) often dramatically slow
down programs if they rely on locks to protect the reference count.

Hans

> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrei at metalanguage.com]
> Sent: Monday, October 18, 2004 9:33 AM
> To: Doug Lea
> Cc: Kevlin Henney; Maged Michael; Doug Lea; Boehm, Hans; Ben 
> Hutchings;
> pugh at cs.umd.edu
> Subject: Re: Slides for tomorrow night
> 
> 
> > 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
>