N-archive/suyu
1
0
Fork 0
mirror of https://git.suyu.dev/suyu/suyu.git synced 2024-11-05 06:22:45 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Kernel/Threads: A thread waking up by timeout from a WaitProcessWideKey may already have an assigned lock owner.

Browse source 
This situation may happen like so:
Thread 1 with low priority calls WaitProcessWideKey with timeout.
Thread 2 with high priority calls WaitProcessWideKey without timeout.
Thread 3 calls SignalProcessWideKey
- Thread 2 acquires the lock and awakens.
- Thread 1 can't acquire the lock and is put to sleep with the lock owner being Thread 2.
Thread 1's timeout expires, with the lock owner still being set to Thread 2.
This commit is contained in:
Subv 2018-06-02 14:06:35 -05:00
parent bbbe34429e
commit 9cd87a6352
1 changed files with 5 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
src/core/hle/kernel/thread.cpp
View file

@ -133,8 +133,11 @@ static void ThreadWakeupCallback(u64 thread_handle, int cycles_late) {
auto lock_owner = thread->lock_owner; auto lock_owner = thread->lock_owner;
// Threads waking up by timeout from WaitProcessWideKey do not perform priority inheritance // Threads waking up by timeout from WaitProcessWideKey do not perform priority inheritance
// and don't have a lock owner. // and don't have a lock owner unless SignalProcessWideKey was called first and the thread
ASSERT(lock_owner == nullptr); // wasn't awakened due to the mutex already being acquired.
if (lock_owner) {
lock_owner->RemoveMutexWaiter(thread);
}
} }
if (resume) if (resume)