Synchronization, Windows style (overview)

Professor Djikstra--Mister Syncronization!

So, I've been doing some heavy work with multithreading on windows lately, and I must say I'm impressed. Win32 went whole-hog for the multithreaded model, and has great Kernel support for some very useful primitives:

If you want to work within your process exclusively, you have Critical Sections, which give are ways to ensure only one thread is executing in a code block at any one time. Nice, but nothing too exciting.

It gets more interesting when you start discussing the Kernel Objects: Mutexes, Semaphores, and Events. As these are Kernel objects, you can use them for synchronization between processes. Coming from the java world, this isn't something I'm used to--Java has built-in support for threading, but up to Java 5, had only Monitors and synchronized blocks. After that, we got Mutexes, Atomic* classes, Semaphores, etc, but still constrained to only one process/Virtual Machine.

A plain-old Kernel Event is a darn useful thing: Spin off some work to a worker thread (or, in my case Overlapped/Async I/O) and wait for the I/O to complete or your timeout to fire. If the I/O's already come back before you enter the WaitForSingleObject or WaitForMultipleObjects, then no problem--you automatically don't wait. In Windows terms,the Kernel object is 'Signaled', so no wait is necessary.

This nicely overcomes the problem in Java where you MUST check before invoking Object.wait() or else you'll block--possibly forever, even if your child operation/process/IO is done.

Semaphores and Mutexes work much the same way--they're cross-process, and have two logical states: Signalled and non-signalled. Faster than Java, anyway!