Slides for tomorrow night

[Andrei Alexandrescu]

Great argument (also many thanks to all for the comments).

Your opinion is not at all controversial. Implementers are moving away 
from refcounting basic_string. True, it took us much longer that you to 
realize that :o).

Andrei

Boehm, Hans wrote:
 > 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
 >>