src/thread/windows/SDL_syscond_srw.c


Log

Author Commit Date CI Message
Cameron Gutman f70e1973 2021-02-08T18:31:08 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.
Ozkan Sezer 01a2f276 2021-01-04T01:23:50 consistently use TEXT() macro with LoadLibrary() and GetModuleHandle() cf. bug #5435.
Sam Lantinga 9130f7c3 2021-01-02T10:25:38 Updated copyright for 2021
Joel Linn 8fc0baad 2020-12-28T11:43:11 Add SDL_cond implementation using Windows Condition Variables Is automatically used when the SRW SDL_mutex implementation is active. Otherwise falls back to the generic implementation. v2: - Rebase onto master fa3ea1051a4b
Joel Linn 2443e51e 2020-12-28T11:42:49 Add optional suffix `_generic` to generic SDL_cond impl Allows for runtime selectable implementation