Re: [boost] Re: On boost.threads

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-09-10 15:28:16

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, September 10, 2001 9:04 AM
Subject: Re: [boost] Re: On boost.threads

> From: <williamkempf_at_[hidden]>
> > --- In boost_at_y..., flameframe_at_h... wrote:
> [...]
> > > http://world.std.com/~jmhart/csmutx.htm.
> [...]
> > This was the article that someone pointed me to.  The conclusion was
> > that CS are only faster if:
> >
> > * There are less than 8 threads total in the process.
> > * You weren't running in the background.
> > * You weren't on an dual processor machine.
>
> The code in the article tested a fairly pathological case; the threads
were
> always competing for the same critical section, and spent no time outside,
> i.e. they immediately tried to reacquire. So the conclusion is more like
>
> * There are, at any moment, less than 8 threads waiting on the same CS.
>
> This is an interesting data point, but I don't think that it's a killer
> argument against CS use.
>
> A common usage of boost::mutex would be making a library thread safe. If
> such a library is accessed from a single thread (fairly common even in
> multithreaded programs) using a win32 mutex would impose a significant
> overhead.
>

I know there is probably a desire to avoid the number of configuration
options for the library, but maybe the right thing to do here is to put
support for critical sections inside #ifdefs (disabled by default).  This
sounds like one of those things that we're not going to learn about except
by experimentation.  Minimizing the effort required to experiment should
help to encourage such experimentation in real-world apps.  IMO this is very
much in the spirit of boost, and it's a pretty localized change, affecting
only two files and nine methods.