Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at