Boost logo

Boost :

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-09-10 08:35:34

From: <williamkempf_at_[hidden]>

> 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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at