Win32 Event Objects
Win32 defines event objects, which are intended to handle the same things as condition variables.
Event objects have a "signaled" state associated with them, however, making them somewhat
problematic to use. There is an interesting paper showing the issues involved in constructing
POSIX-style condition variables from event objects (see Threads Research). This paper also
highlights the difficulties in using event objects correctly.
Win32 Critical Sections
In Win32 the term critical section is used to describe a simple mutex. The major distinction
between Win32's mutexes and Win32's critical sections is that the former can be defined to be
cross-process, whereas the latter cannot. All Win32 synchronization variables other than critical
sections are kernel objects. Their handles must be closed before the kernel structures are released.
They are also much slower than critical sections by about two orders of magnitude (!).
Multiple Wait Semaphores
In Win32 it is possible to wait for (1) any one of a set of synchronization variables or (2) all of
that set. In POSIX and Java you would write the program differently and simply have a condition
variable (wait/notify) waiting on a complex condition.
In Win32, several special functions are defined: InterlockedIncrement(),
InterlockedDecrement(), and InterlockedExchange(). As their names suggest, they
perform their tasks automatically without the need of an explicit lock. This makes them quite fast
but limits their usefulness greatly. (Sure, you've incremented the value, but you don't know if
someone else incremented it a microsecond later.) These are implemented by the Digital compiler
The things you can do with them include reference counting, semaphores, and not much else.
These types of operations are not part of either POSIX or Java, and the requisite instructions are
not on all CPU architectures.
A question asked fairly often is how one can build message queues for threads--queues where one
thread can line up requests for another thread to process. If this is truly what you need in your
program, the answer is quite simple: Build a producer/ consumer model with a queue as shown
earlier. This gives you both complete control over your program and a simple programming model.
What more could you ask for?
Win32 implements a kernel-level message queue that you can use for the same purpose. As it is
part of the Win32 library, it makes sense to use it for cross-process communication, especially
when you don't have control over all the source code. Otherwise, in a single process, it simply
imposes too heavy a burden, in both CPU time and code complexity.
Search WWH :