516
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − − The Nintendo 3DS offers support for threading through use of [[SVC]] calls. Line 100:
Line 98: − + Line 266:
Line 264: − + − + − * KInterruptEvent: ??? − + − + − + Line 290:
Line 287: − − == Ciritical Section (light-weight mutex) == − − == CriticalSection::Initialize == − − Same thread ownership as a mutex ? − − === CriticalSection::Enter === − − === CriticalSection::Leave === − − == Light Semaphore ? == − − Does it exist ? − − == Light Event ==
→Synchronization
This page is a work in progress. Put everything related to multi-threading here, threads, synchronization, multi-core support, etc.
This page documents all kernel functionality for managing multiple processes and threads as well as handling synchronization between them.
= Processes =
= Processes =
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.
* KClientPort: Wakes if max sessions not reached (free session available)
* KClientPort: Wakes if max sessions not reached (free session available)
* KClientSession: ???
* 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
* 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
* KServerSession: Waits for an IPC command to be submitted to the server process
* KServerSession: Waits for an IPC command to be submitted to the server process
* KThread: Waits until the thread terminates
* KThread: Waits until the thread terminates
* KTimer: ???
* KTimer: Wakes when timer activates (this also clears the timer if it is oneshot)
Most synchronization systems seem to have both a "normal" and "light-weight" version
Most synchronization systems seem to have both a "normal" and "light-weight" version
== Mutex (normal) ==
== Mutex ==
For Kernel implementation details, see [[KMutex]]
For Kernel implementation details, see [[KMutex]]
=== ReleaseMutex ===
=== ReleaseMutex ===
== Semaphore ==
== Semaphore ==
== Event ==
== Event ==
== Address Arbiters ==
== Address Arbiters ==