SemWait() too expensive on Windows even when not blocking

SDL_SemWait() on Windows calls WaitForSingleObject(), which obtains a kernel lock all of the time and thus has significant overhead even when it returns right away–from an Intel forum, it’s about 40 times slower than a user-space lock. It would make sense to change this to only call when the program actually expects it to block. A user-space lock should be done using interlocked operations similar to the way it’s in pthreads-win32, then WFSO called if it has to wait.

SDL_SemWait() on Windows calls WaitForSingleObject(), which obtains a kernel lock all of the time and thus has significant overhead even when it returns right away–from an Intel forum, it’s about 40 times slower than a user-space lock. It would make sense to change this to only call when the program actually expects it to block. A user-space lock should be done using interlocked operations similar to the way it’s in pthreads-win32, then WFSO called if it has to wait.

I don’t have time to look at it right now, do you have a patch?

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC