But the proxy thread's own message queue, which it shares with the Main/UI thread, will be unlocked. When the proxy thread forwards messages to the virtual machine, the two threads share a common resource (the virtual machine's message queue) which means that if the VM thread is deadlocked, the proxy thread may deadlock as well. 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 extra rendering threads 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'. Communication between the Main/UI thread and other worker threads should be conducted through a proxy thread that simply queues messages from the main threads, and re-dispatches messages to workers.
Pcsx2 extra rendering threads software#
For example set it to 3 for quad core processors (1 for PCSX2 and 3 for GSdx software rendering). This is typically called the Main or UI thread. Extra Rendering threads: This option determines how many threads GSdx will use while rendering to take advantage of all the vacant cores your CPU might have (note that it will only be useable for software rendering). There must be at least one thread in the application that does not depend on any other thread.In order to make an application as robust against deadlock as possible, it should adhere to the following basic rules: If you plan to be doing programming work on PCSX2 user interfaces or virtual machine management, then this section will be an important read. This section will cover advanced threading concepts that are important for allowing a program like PCSX2 to be able to operate smoothly - responsive to the user and relatively deadlock-free. For definitions of Mutex, Semaphore, and Atomic Operations, please use google or see our Threading Basics section.
0 kommentar(er)
