Re: On boost.threads

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