PCSX2 Documentation/Threading Advanced: Difference between revisions
Jump to navigation
Jump to search
PCSX2 Documentation/Threading Advanced (view source)
Revision as of 20:10, 19 July 2015
, 19 July 2015no edit summary
No edit summary |
No edit summary |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
For definitions of Mutex, Semaphore, and Atomic Operations, please use google or see our [[Threading Basics]] section. 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. If you plan to be doing programming work on PCSX2 user interfaces or virtual machine management, then this section will be an important read. | ''Threading In-Depth'' | ||
For definitions of Mutex, Semaphore, and Atomic Operations, please use google or see our [[PCSX2_Documentation/Threading Basics | Threading Basics]] section. 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. If you plan to be doing programming work on PCSX2 user interfaces or virtual machine management, then this section will be an important read. | |||
==Avoiding Unresponsiveness and Deadlock== | ==Avoiding Unresponsiveness and Deadlock== | ||
| Line 16: | Line 18: | ||
A 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). It only locks shared resources -- a message queue list -- for extremely short periods of time, and only to add and remove messages. 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. But the proxy thread's own message queue, which it shares with the Main/UI thread, will be unlocked. Thusly, the Main thread does not risk deadlock. | A 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). It only locks shared resources -- a message queue list -- for extremely short periods of time, and only to add and remove messages. 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. But the proxy thread's own message queue, which it shares with the Main/UI thread, will be unlocked. Thusly, the Main thread does not risk deadlock. | ||
{{PCSX2 Documentation Navbox}} | |||