Re: Standard Library problems w/multi-threading

From: williamkempf_at_[hidden]
Date: 2001-09-10 22:19:30

--- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
> Beman Dawes wrote:
> > *  Provide better, thread-safe, C++ oriented solutions.  Haven't 
our Random
> > Number and Tokenizer libraries already done that for the first 
two on the
> > list?  (I haven't looked at the code; is it thread-safe?) 
> 
> Both Random Number and Tokenizer don't have any global state I'm
> aware of, so they're thread-safe in the sense that distinct objects
> of the same type (or of different type) can co-exist in different
> threads without doing harm to one another.  It does not appear
> to be useful to wrap either Random Number or Tokenizer into
> thread-synchronization primitimes at the boost library level.
> (No sane person will compete for a single pseudo-random number
> generator from different threads.)

99.9999% of all objects should not be fully thread safe.  The cost is 
prohibitive and the granularity is almost always wrong.  They should 
only be "thread safe at the object level", meaning that as long as an 
object instance is never shared between threads or is protected 
externally by a mutex if it is it should not become corrupt because 
of the presence of multiple threads.

> > Opinions?
> 
> Provide C++ replacements, don't muck with xxx_r().

I agree, except that xxx_r() and xxx() replacements can vastly help 
with legacy code.  I see a place for both.

Bill Kempf