You may not have a need for it, and that's fine. But please refrain from pushing your ideals upon others in the C++ forum. This is about standard, portable C++.
In this case the OP was asking for examples of multi-threading using Windows API, which was the key point of the examples. I grabbed what I already had as working examples. If the OP or anyone else actually expressed interest in this, I would take the time to convert the example to proper C++, but as it stands now, it doesn't seem anyone cares.
So basically you don't think threads are platform specific?
As mentioned in my prior posts and in the example code, Windows API includes WaitForMultipleObjects(), which is used in the GetNode function to wait for both a mutex and a semaphore with a non zero count, then decrement the non-zero semaphore count, with a single "atomic" call to the operating system. This simplifies the code and eliminates any issues related to thread priority. Also as mentioned in prior posts, most of the operating systems I've worked with going back to the 1970's have something similar to WaitForMultipleObjects(), but there's no native equivalent for POSIX, or std::thread.
Not anymore with C++11, they aren't.
That being said, you should now typically almost always prefer task-based parallelism to anything else. This includes the use of std::async and the resulting std::future. After that, std::thread should be your next goto. Using platform-specific threading APIs is now a bad idea. I darn near pooped myself the first time I got threaded code to compile on both Windows and Linux and it's all thanks to C++11.
The OP is working on a game, which is probably using other Windows specific stuff, such as directx for graphics and controller input . There's still the issue of lack of support for the equivalent of Windows (or XBOX) WaitForMultipleObjects with POSIX or std::thread.
Semaphores are (counted) mutexes. There is a function that grabs multiple locks at the same time. You can make your own WaitForSingleObject/WaitForMultipleObjects class/functions in C++. It's not a perfect 1:1 replacement, but it's still better than nothing and you're not missing out on functionality just because you use it.
So? There's nothing saying that can't mix the C++ standard library and other windows-specific stuff such as directx.
I'm actually not sure what this is but it sounds like either joining on a series of threads or waiting on multiple asynchronous values to resolve. If if it's threads, then it's just simple join calls with a condition variable.WaitForMultipleObjects
The caller can specify to wait for any or for all of the objects to be signaled. In the example I posted, a mutex is used for ownership of a message queue (linked list), and a semaphore for the count of messages in the queue. A single "atomic" call with WaitForMultipleObjects() allows a thread to pend for both the mutex and a non-zero semaphore count, then decrements the semaphore count, and returns back to the previously pending thread. This eliminates any issues related to thread priority.
In the multi-threaded operating systems and applications I've worked with going back to the 1970's (mainframes and mini-computers), the primary method of communication between threads was message queues, but there was also an event for exception handling (like shutdown), and a timer, so the equivalent of WaitForMultipleObjects was used, waiting for any of the objects to be signaled: message, event, or timer, to be signaled. The same feature can be found in many of the RTOS implementations for embedded devices.
It seems like it can almost be expressed with condition variables nowadays. C++11 brought more than just std::thread.
Going back to the OP's question though... Have they even posted since? I think we all got distracted by the very C-like code XD
The Windows API seems kind of cool though. I was reading up on WaitForMultipleObjects on the MSDN. As much as it pains me to say this, M$ has some pretty good docs.