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