From: williamkempf_at_[hidden]
Date: 2001-09-09 21:08:12
--- In boost_at_y..., flameframe_at_h... wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
>
> > > I'll be interested in your research. MS people that know the
> > details claim
> > > that a critical section is incredibly optimized and should beat
a
> > mutex in
> > > any reasonable scenario.
> >
> > It wasn't my research. It was research that Alexander Terekhov
> > (spelled from memory, sorry if I buthered it) found on the net.
>
> You could look also to detailed comparision - "Thread Performance,
> Critical Sections, and Mutexes" by Johnson M. Hart on
> http://world.std.com/~jmhart/csmutx.htm.
>
> BTW. I am agree that mutex is more _universal_ solution from a
> performance point of view. But to be fair - CS are faster in simple
> design. I believe that possibility to support them should be at
least
> taken in account.
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.
To me this means that simple testing yields good CS performance
results, but any real world program is better off with a full blown
mutex.
I'm not adverse to supporting a CS implementation. However, I
originally chose not to for the following reasons:
* You get either construction and destruction hits from using a PIMPL
idiom or you must include Windows.h in the Boost.Threads headers,
which I simply don't want to do. (This can be worked around by
emulating a CS ala OPTEX from the MSDN.)
* According to this research paper _most_ programs won't benefit from
a CS design.
* It's trivial to code a (non-portable) critical_section class that
follows the Mutex model if you truly can make use of this.
For now I think I've made the right choice, though down the road we
may change the implementation to use a critical section or OPTEX.
Bill Kempf