Re: On boost.threads

From: williamkempf_at_[hidden]
Date: 2001-09-10 21:33:05

--- In boost_at_y..., "Ed Brey" <edbrey_at_y...> wrote:
> From: <williamkempf_at_h...>
> 
> > 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.
> 
> Ouch.  The project I'm working on has a Windows GUI application 
running
> in a GUI thread and a network communication subsystem working in a
> separate thread.  The reason for the thread separation is not for
> multi-processor parallelism, but rather so that the GUI folks can 
block
> and take all day on some operations without having to worry about 
the
> soft real-time nature of the network.  This application will almost
> never be run on a dual processor computer (at least not for years to
> come), will be run in the foreground, and will have just a handful 
of
> threads.  Yet performance is important since customers' computers 
are
> often old and slow and there is a lot of data to handle.
> 
> I have a hard time believing that such a situation as mine is all 
that
> rare.

Not rare, but not the norm for MT applications either.  Don't take 
this wrong from me, I am not suggesting we totally for go critical 
sections (or more likely an optex) in the implementation.  My 
reasoning is simply that there's some evidence that a CS actually 
performs worse in some situations (which I would consider to be the 
norm) so given the issues I've laid out with the implementation I 
chose to initially go with just a mutex.  I expect that we'll do some 
research and some experimentation on this issue and may very well 
change the implementation later.  However, it's just an 
implementation detail and *IF* someone has immediate need for a CS 
implementation it doesn't take much to roll your own.

> A macro to choose the implementation method would do just the trick.
> This also could would open the door to allowing <windows.h> into the
> header without any concern of harm, since the default could be to 
use
> the mutex.

I'm not totally adverse to this approach, though I think it adds 
unnecessary complexity and makes it harder to switch completely to a 
CS/optex implementation in the future.

Bill Kempf