

It only locks shared resources - a message queue list - for extremely short periods of time, and only to add and remove messages. So how do we make the main/ui thread not be dependent on our stall-prone virtual machine threads? By using a proxy queue thread to break the dependency chain!Ī proxy queue thread works as a safety valve because the task it performs is simple enough that we can guarantee it will not deadlock (or at least, if a deadlock does occur its because of some fairly critical system failure). There would be no way for it to communicate with other threads without them. Having our main thread completely avoid the use of mutexes and semaphores, however, is an unrealistic impossibility. If it stalls on a mutex that is acquired by another thread that is busy or deadlocked, the main thread will stall or deadlock itself.
#Pcsx2 thread creation failure free#
This is why a Main/UI thread must be as free as possible of mutexes and semaphores. If thread 'B' thread deadlocks while it has acquired a mutex or sempahore, thread 'A' will also deadlock when it tries to acquire the resource.

If thread 'B' locks a multi-threaded resource (mutex or semaphore) indefinitely, and Thread 'A' attempts to acquire the same resource, Thread A will also stall. Thread 'A' is said to be dependent on thread 'B' if it has any shared mutex or semaphore with thread 'B'.
