C++11 thread requirements

[thrimbor]

This implements all the winapi functionality required to enable the C++11 thread support in libc++: The InitOnce* API, Slim Reader/Writer Locks, and condition variables (I intended to split them up, but it just caused merge conflicts everywhere).

The support for condition variables is basically equivalent to how I implemented it for PDCLib, but it's modified for the lock types winapi provides. One crucial difference to the way this works on Windows, is that Windows uses keyed events to implement condition variables. We don't have that feature in the Xbox kernel, so instead, all functions use the InitOnce* API for initialization of normal events, and an additional function (which doesn't exist on Windows) is provided, DestroyConditionVariable, which frees the events. My thread-support patch for libc++ hooks that function up when building on nxdk.

I've written some test code for SRW locks here, and some test code for the InitOnce* API here.

[dracc]

Looks good to me! 👍
Read the code, compiled and tried it.

I ran the supplied tests successfully.

The tests behave as expected. 💪

[sam-itt]

Built and ran the two test cases: Gives the expected output on both xqemu and real hardware.
Note: The lock/unlock sequence of SRW locks sample is exactly the same on xqemu and my real xbox.

[thrimbor]

Just noticed that one of the code changes was accidentally spread over two commits. I fixed it with a rebase, the actual code didn't change.

[dracc]

Tested 3aae926 using the supplied tests both on XQEMU and on real hardware. Still behaves as expected. 👍

[JayFoxRox]

I don't see anything about this disallowing lpContext on MSDN; I assume this was tested against Windows?

[thrimbor]

Maybe? Tbh, I don't remember and currently can't find any test code on my HDD. I did switch the machine I do my experiments on a while ago though, so maybe I just wiped it with the old Windows installation.

I did just look up that part in ReactOS though, and it does the same here.

[JayFoxRox]

nit: There's a lot of redundancy with SleepConditionVariableCS that could have been factored out; fine as-is though.

[thrimbor]

True, but the lock stuff is pretty much spread over the entire function. I think factoring it out would make the control flow much harder to understand.

[JayFoxRox]

nit: Before creating new events, you could probably check (assert) if this thing is really clean at this point:

• ConditionVariable->initOnce.Ptr == 0 (this assumption would currently be broken after re-using a CONDITION_VARIABLE without manually setting CONDITION_VARIABLE_INIT after UninitializeConditionVariable)
• ConditionVariable->waitCount == 0
• ConditionVariable->eventHandles[0] == INVALID_HANDLE_VALUE
• ConditionVariable->eventHandles[1] == INVALID_HANDLE_VALUE

You'd just have to reintroduce the initialization of the events to INVALID_HANDLE_VALUE in InitializeConditionVariable.
These assumptions should always be true then, because they come from CONDITION_VARIABLE_INIT or InitializeConditionVariable.

However, I'll leave up to you wether you consider this a useful addition that's worth adding.

[thrimbor]

Ah, I forgot about this.
We can't really check for ConditionVariable->initOnce.Ptr == 0 here, because the InitOnce API functions will change the value of this variable before calling this function, so it's never zero here.
I did add checks for the other conditions though.

[JayFoxRox]

I'm merging this untested, because it has been here for way too long.
We can iterate if it's broken.

[...] condition variables is basically equivalent to how I implemented it for PDCLib

There have been a couple of improvements in this new implementation during this review, which probably aren't in PDCLib yet.
So please consider improving other variants of this code in PDCLib if they still exist @thrimbor