Use GetThreadId/WakeupThread/SleepThread instead of CreateSema/SignalSema/WaitSema

[uyjulian]

Will improve handling in borderline cases where semaphore limit is exhausted
Replaced in the following case:

• initial_value=0
• SignalSema was in callback
• CreateSema/WaitSema was in same thread

[sp193]

I feel that you're just switching out who will actually get to use the semaphores. The libraries won't use a lot of semaphores, so shouldn't we be addressing the source of the 200 or something semaphores getting used?

It's subjective and probably down to preferences. I used to suggest that we don't deviate from how Sony designed the SDK. Any bugs that appear because of edge cases, would be caused by us and end up being for us to solve. However, what you're doing does seem more efficient and it's an interesting improvement over Sony's original design.

One area to note may be how iWakeupThread() works. The syscall is bugged in all EE kernels, whereby it cannot wakeup a thread that is presently in RUN state, despite the documented behaviour. So there's an official patch (which we also have) that will schedule a wakeup via WakeupThread(), via a thread that runs at the highest priority. In terms of efficiency, it's a longer path... but it may not mean anything. Does this matter for the accuracy of nanosleep()? If not, then this is more of a FYI.