In real PS3 (it seems), when a thread with a higher priority than the caller is signaled and that there is available space on the running queue for the other hardware thread to start It prioritizes signaled thread caller's hardware thread switches instantly to the new thread code while signaling to the other hardware thread to execute the caller's code.
Resulting in a delay to the caller after such thread is signaled
* Linux: set timerslack to minimum value
- Linux delays the wakeup of threads to save power, this feature isn't needed for this application
* Utils: Add detection for waitpkg and monitorx extensions
- These instructions are used for user mode wait instructions
* lv2: Use user mode wait instructions instead of yielding when appropriate
Timeline of the race:
1. The PPU is in SLEEP state. state = suspend.
2. lv2_obj::awake is called on the traced thread and is now in ONPROC state, state = signal.
3. lv2_obj::awake is called by another thread externally with a priority higher than our traced thread and appends it to g_pending. state = suspend + signal.
4. lv2_obj::sleep/set_priority (higering priority) is called on any thread which is in ONPROC. Causing it to enter SLEEP or RUNNING state, while the traced thread is back in queue in ONPROC. state = suspend + signal.
5. The traced thread finally calls lv2_obj::awake on itself, g_pending decrements to 0 and we a have a rescheduling event, after XOR state = 0!!! (no signal)
6. In check_state: cpu_sleep_called is now true and remains this way.
7. Another thread with a higher prioty kicks in and appends the traced thread into g_pending. state = suspend.
8. The traced thread is at cpu_thread::cpu_wait(), and that's where it's gonna spend the rest of its life.
Fix and optimize sys_ppu_thread_yield
Fix LV2 syscalls with timeout bug. (use ppu_thread::cancel_sleep instead)
Move timeout notification out of mutex scope
Allow g_waiting timeouts to be awaked in scope
