I just wanted to comment on the use of Sleep(0).
Unless you know exactly what you are doing, don’t do this. The reason is that Sleep(0) only gives up the remainder of the current thread’s time-slice if there is a thread with the same or higher priority waiting to run.
This is something ATI at least used to do in their ICD that took me literally days to hunt down when my app locked up for several seconds at a time. Basically, they used a “poor man’s critical section” in hopes of busywaiting would gain a nanosecond here or there, while completely locking up a uniprocessor system in case the window-managing thread is running at another priority than a/the rendering thread.
Please don’t make the same mistake. Busy-waiting is usually bad.
To display two alternatives (as this is platform dependent):
-
If you need to get notified ASAP, use an event. Just before you wait for the event, raise the thread priority (to a priority higher than the thread you’re waiting for). When wait returns, immediately lower your thread priority back. Using this, you will get notified immediately when the event is signalled (I’m fairly certain it will in fact, on a uni-CPU system, be faster than the busy-waiting approach).
-
Use a critical section as both synchronizing primitive and the signal (using the same raise/revert thread priority idea), but prepend the call to enter the critical section with a call to TryEnterCriticalSection. On a good day that’ll save the three kernel calls to raise/lower thread pri. and waiting for the mutex.
AMD/ATI: Feel free to fix that crappy “home-made” (dead-)locking and use what I explained here.