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
rare.

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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk