Multi-threading - Revision history

Kynex7510: Fake news

2024-08-06T11:04:07Z

Fake news

← Older revision		Revision as of 15:04, 6 August 2024
Line 189:		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 ===

TuxSH at 10:45, 19 August 2023

2023-08-19T08:45:48Z

← Older revision		Revision as of 12:45, 19 August 2023
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, 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. Address arbiters can be used to implement process-local synchronization primitives.		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.

Fincs: /* Threads */ Remove misconceptions about Horizon threading

2023-08-18T21:36:36Z

Threads: Remove misconceptions about Horizon threading

← Older revision		Revision as of 01:36, 19 August 2023
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. 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.

Peachy: Undo my derp

2023-08-12T08:41:56Z

Undo my derp

← Older revision		Revision as of 12:41, 12 August 2023
Line 141:		Line 141:

	'''Details'''		'''Details'''
	Makes the currently running thread exit. When a thread exits, all mutex objects it owns are released and made available to other threads.
			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 ===

Peachy: /* ExitThread */

2023-08-12T08:41:20Z

ExitThread

← Older revision		Revision as of 12:41, 12 August 2023
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 ===

Peachy at 10:21, 12 August 2023

2023-08-12T08:21:05Z

← Older revision		Revision as of 12:21, 12 August 2023
Line 128:		Line 128:
	The stacktop must be aligned to 0x8-bytes, otherwise when not aligned to 0x8-bytes the ARM11 kernel clears the low 3-bits of the stacktop address.		The stacktop must be aligned to 0x8-bytes, otherwise when not aligned to 0x8-bytes the ARM11 kernel clears the low 3-bits of the stacktop address.

	The processorid parameter specifies which processor the thread can run on. Non-negative values correspond to a specific CPU. (e.g. 0 for the Appcore and 1 for the Syscore on Old3DS) Special value -1 means all CPUs, and -2 means the default CPU for the process (Read from the [[NCCH/Extended Header\|Exheader]], usually 0 for applications, 1 for system services). Games usually create threads using -2.		The processorid parameter specifies which processor the thread can run on. Non-negative values correspond to a specific CPU. (e.g. 0 for the Appcore and 1 for the Syscore on Old3DS. On New3DS, IDs 2 and 3 are also valid, referring to the 2 additional CPU cores) Special value -1 means all CPUs, and -2 means the default CPU for the process (Read from the [[NCCH/Extended Header\|Exheader]], usually 0 for applications, 1 for system services). Games usually create threads using -2.

	The thread priority value must be in the range 0x0..0x3F. Otherwise, error 0xE0E01BFD is returned.		The thread priority value must be in the range 0x0..0x3F. Otherwise, error 0xE0E01BFD is returned.

TuxSH: /* Synchronization */

2016-12-24T23:59:56Z

Synchronization

← Older revision		Revision as of 02:59, 25 December 2016
Line 265:		Line 265:
	* KClientPort: Wakes if max sessions not reached (free session available)		* KClientPort: Wakes if max sessions not reached (free session available)
	* KClientSession: Always false?		* KClientSession: Always false?
	* KDebug: ~~???~~		* KDebug: Waits until a debug event is signaled (the user should then use svcGetProcessDebugEvent to get the debug event info)
	* KDmaObject: ???		* KDmaObject: ???
	* KEvent: Waits until the event is signaled		* KEvent: Waits until the event is signaled
	* KInterruptEvent: ???
	* KMutex: Acquires a lock on the mutex (blocks until this succeeds)		* KMutex: Acquires a lock on the mutex (blocks until this succeeds)
	* KProcess: Waits until the process exits		* KProcess: Waits until the process exits/is terminated
	* KSemaphore: This consumes a value from the semaphore count, if possible, otherwise continues to wait		* KSemaphore: This consumes a value from the semaphore count, if possible, otherwise continues to wait
	* KServerPort: Waits for a new client connection, upon which svcAcceptSession is ready to be called		* KServerPort: Waits for a new client connection, upon which svcAcceptSession is ready to be called

Neobrain: /* Threads */

2016-10-12T18:48:59Z

Threads

← Older revision		Revision as of 22:48, 12 October 2016
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 thread scheduler is cooperative, 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.		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.

	0xFFFF8000 is a handle alias for the currently active thread.		0xFFFF8000 is a handle alias for the currently active thread.

Neobrain: Content moved to CTR API

2016-09-25T08:58:21Z

Content moved to CTR API

@@ Line 288: / Line 288: @@
 === ReleaseMutex ===
 == Semaphore ==
 == Event ==
 == Address Arbiters ==

Bond697 at 14:29, 31 August 2016

2016-08-31T12:29:05Z

@@ Line 288: / Line 288: @@
 === ReleaseMutex ===
 == Semaphore ==
 == Event ==
 == Address Arbiters ==