sdl2_frt/src/thread/windows
Cameron Gutman f70e197363 Fix waiting on condition variables with the SRW lock implmentation
When SleepConditionVariableSRW() releases the SRW lock internally, it causes
our SDL_mutex_srw state to become inconsistent. The lock is unowned yet inside,
the owner is still the sleeping thread and more importantly the owner count is
still 1.

The next time someone acquires the lock, they will bump the owner count from 1
to 2. At that point, the lock is hosed. From the internal lock state, it looks
to us like that owner has acquired the lock recursively, even though they have
not. When they call SDL_UnlockMutex(), it will see the owner count > 0 and not
call ReleaseSRWLockExclusive().

Now when someone calls SDL_CondSignal(), SleepConditionVariableSRW() will start
the wakeup process by attempting to re-acquire the SRW lock. This will deadlock
because the lock was never released after the other thread had used it. The
thread waiting on the condition variable will never be able to wake up, even if
the SDL_CondWaitTimeout() function is used and the timeout expires.
2021-02-10 10:22:20 -05:00
..
SDL_syscond_srw.c Fix waiting on condition variables with the SRW lock implmentation 2021-02-10 10:22:20 -05:00
SDL_sysmutex_c.h Updated copyright for 2021 2021-01-02 10:25:38 -08:00
SDL_sysmutex.c Fix waiting on condition variables with the SRW lock implmentation 2021-02-10 10:22:20 -05:00
SDL_syssem.c consistently use TEXT() macro with LoadLibrary() and GetModuleHandle() 2021-01-04 01:23:50 +03:00
SDL_systhread_c.h Updated copyright for 2021 2021-01-02 10:25:38 -08:00
SDL_systhread.c use WIN_StringToUTF8W instead of WIN_StringToUTF8 where needed (#2) 2021-01-05 15:50:02 +03:00
SDL_systls.c Updated copyright for 2021 2021-01-02 10:25:38 -08:00