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.