Multi-threading: Difference between revisions

Peachy (talk | contribs)
No edit summary
Kynex7510 (talk | contribs)
m Fake news
 
(4 intermediate revisions by 3 users not shown)
Line 98: Line 98:
Lower priority values give the thread higher priority. For userland apps, priorities between 0x18 and 0x3F are allowed. The priority of the app's main thread seems to be 0x30.
Lower priority values give the thread higher priority. For userland apps, priorities between 0x18 and 0x3F are allowed. The priority of the app's main thread seems to be 0x30.


The [[Glossary#appcore|appcore]] thread scheduler primarily uses a cooperative design, therefore if a thread takes up all the CPU time (for example if it enters an endless loop), all the other threads that run on the same CPU core won't get a chance to run. The main way of yielding another thread is using an address arbiter. In certain cases, execution of the current task may be preempted regardless, for instance when a thread was waiting on svcSendSyncRequest to return.
The [[Glossary#appcore|appcore]] thread scheduler, in typical real-time operating system fashion, implements a simple preemptive algorithm based around multiple thread priority levels. This algorithm guarantees that the currently executing thread is always the highest priority runnable thread (also known as SCHED_FIFO). In other words, a thread will be interrupted (preempted) if and only if a higher priority thread is woken up, by means of an event (i.e. svcSendSyncRequest) or similar. Contrary to typical desktop operating systems, no timeslice-based scheduling is performed, which means that if a thread uses up all available CPU time (for example if it enters an endless loop), all other threads with equal or lower priority that run on the same CPU core won't get a chance to run. Yielding to other threads is otherwise done by means of synchronization primitives (thread sleep, mutex, address arbiter, etc.). Address arbiters can be used to implement process-local synchronization primitives.


0xFFFF8000 is a handle alias for the currently active thread.
0xFFFF8000 is a handle alias for the currently active thread.
Line 139: Line 139:
'''Signature'''
'''Signature'''
  void ExitThread(void);
  void ExitThread(void);
'''Details'''
Makes the currently running thread exit. When a thread exits, all mutex objects it owns are released and made available to other threads.


=== SleepThread  ===
=== SleepThread  ===
Line 185: Line 189:
'''Signature'''
'''Signature'''
  Result GetThreadId(u32* threadId, Handle thread);
  Result GetThreadId(u32* threadId, Handle thread);
'''Details'''
It seems that only the thread itself or one of its parent can get the ID. Calling this on the handle of a sibling or parent seems to always yield the ID 0.


=== GetThreadInfo ===
=== GetThreadInfo ===