Difference between revisions of "Unit Threads"

Revision as of 04:59, 2 March 2023

Return to Unit Reference

Description

Ultibo Threads Interface unit

Locking Primitives

Spin -

A simple spin lock for fast mutually exclusive access to data. Threads "spin" while waiting to acquire the lock and do not yield the CPU unless pre-empted.

Non recursive (can only be acquired once by the same thread)

Includes IRQ/FIQ entry and exit routines to Save/Restore the IRQ/FIQ state.

Suitable for use by Interrupt handlers if non interrupt callers use the IRQ/FIQ entry and exit routines to Lock and Unlock.

Suitable for use on multiprocessor systems if the lock is allocated from shared memory (Determined during initialization).

Not recommended for long held operations or holding during I/O operations.

Access is not serialized, the next thread to try obtaining the lock when it is released will succeed even if that thread was not the first waiting.

Usage:

Create/Destroy

Spin locks are created using SpinCreate() and destroyed using SpinDestroy(), these functions should not be called from within an Interrupt handler. Lock/Unlock (Data accessed only by threads)

To synchronize data access between threads each thread should call SpinLock() before accessing the data and SpinUnlock() when finished accessing the data. These calls do not affect the state of IRQs or FIQs and therefore do not impact interrupt latency. Lock/Unlock (Data accessed by threads and interrupt handlers)

To use a Spin lock to synchronize data access between threads and an interrupt handler each thread should call SpinLockIRQ() or SpinLockFIQ(), depending on whether the interrupt handler is servicing IRQ or FIQ requests, before accessing the data and SpinUnlockIRQ() or SpinUnlockFIQ() when finished accessing the data. These calls disable interrupts before acquiring the lock (with deadlock protection) and restore interrupts after releasing the lock and therefore should only be used to protect very short sections of code accessing shared data to minimize the impact on interrupt latency.

Interrupt handlers should call SpinLock() before accessing the data and SpinUnlock() when finished accessing the data. In a Uniprocessor system it is technically not necessary for interrupt handlers to call lock/unlock as the use of IRQ/FIQ disable/enable will prevent interrupt handlers from executing while a thread has the lock. On a Multiprocessor system however interrupt handlers can execute on one processor while a thread is executing on another (which will not deadlock), to correctly synchronize data access both threads and interrupt handlers should call the appropriate lock/unlock before and after access to the data.

Lock Hierarchy -

It is safe to acquire one lock using SpinLock() then another lock using SpinLock() and then release them in reverse order.

It is also safe to acquire one lock using SpinLock() then another lock using SpinLockIRQ(or FIQ)() and then release them in reverse order.

It is NOT safe to acquire one lock using SpinLockIRQ(or FIQ)() then another lock using SpinLock() and then release them in reverse order. This is because the first SpinLockIRQ(or FIQ)() can disable the scheduling and prevent thread preemption. If another thread is already holding the second lock then this sequence will deadlock (except on a multicore system where the other thread is running on a different CPU).

It is also safe to acquire one lock using SpinLockIRQ(or FIQ)() then another lock using SpinLockIRQ(or FIQ)() and then release them in reverse order. In this case you must ensure that any thread acquiring the second lock also calls SpinLockIRQ(or FIQ)() to thereby avoid the deadlock.

It is NOT safe to acquire one lock using SpinLockIRQ(or FIQ)() then another lock using SpinLockIRQ(or FIQ)() and then release them in the SAME order. If the situation absolutely requires this behaviour then you must use SpinExchangeIRQ(or FIQ)() when holding both locks in order to reverse the order of the IRQ or FIQ re-enabling.

Mutex -

A mutually exclusive lock for controlling access to data. Threads yield while waiting to acquire the lock.

Non recursive (can only be acquired once by the same thread) (Recursive if MUTEX_FLAG_RECURSIVE specified)

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems if the lock is allocated from shared memory (Determined during initialization).

Recommended for long held operations or holding during I/O operations.

Access is not serialized, the next thread to try obtaining the lock when it is released will succeed even if that thread was not the first waiting.

Usage:

Create/Destroy

Mutex locks are created using MutexCreate() and destroyed using MutexDestroy(). The MutexCreateEx() function allows additional options to be specified including if the creating thread is the initial owner and flags such as MUTEX_FLAG_RECURSIVE.

Lock/Unlock

To use a Mutex lock to synchronise data access between threads each thread should call MutexLock() before accessing the data and MutexUnlock() when finished accessing the data.

The MutexTryLock() function will attempt to lock the Mutex but will return an error instead of waiting for it if already locked.

Lock Hierarchy -

It is safe to acquire one lock using MutexLock() then another lock using MutexLock() and then release them in reverse order.

It is also safe to acquire one lock using MutexLock() then another lock using MutexLock() and then release them in the SAME order.

It is safe to acquire a Mutex lock using MutexLock() then aquire a Spin lock using SpinLockIRQ(or FIQ)().

It is NOT safe to acquire a Spin lock using SpinLockIRQ(or FIQ)() then acquire a Mutex lock using MutexLock().

CriticalSection -

A mutually exclusive lock for serializing access to data. Threads are placed on a wait list while waiting to acquire the lock.

Recursive (can be acquired multiple times by the same thread)

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Recommended for long held operations or holding during I/O operations.

Access is serialized, the next thread to obtain the lock when it is released will be the thread that has been waiting longest (See also stolen wakeups below).

Usage:

Create/Destroy

Critical Sections are created using CriticalSectionCreate() and destroyed using CriticalSectionDestroy().

The CriticalSectionCreateEx() function allows specifying additional flags and options for the lock.

Lock/Unlock

To use a Critical Section to synchronise data access between threads each thread should call CriticalSectionLock() before accessing the data and CriticalSectionUnlock() when finished accessing the data. A CriticalSectionTryLock() function is also available which will not wait if the lock is unavailable and will return immediately with an error.

Because Critical Sections place waiting threads on a wait list they also include the option to specify a timeout value so a thread will not wait indefinitely to obtain the lock by calling CriticalSectionLockEx().

The CriticalSectionLockEx() function will return ERROR_SUCCESS if the lock was obtained, ERROR_WAIT_TIMEOUT if the timeout value elapsed before obtaining the lock and ERROR_WAIT_ABANDONED if waiting was abandoned because the lock was destroyed or another thread called ThreadAbandon() with the handle of the waiting thread.

It is critical that the return value be checked when using timeouts in order to be certain that the lock was obtained before accessing the protected data, failure to do so may result in data corruption if multiple threads make changes at the same time.

Lock Hierarchy -

All serialized locks and synchronization objects generally follow the same principles as Mutex locks above.

It is safe to acquire and release most combinations of serialized objects in any order except where doing so would create a deadlock between threads where thread 1 holds object A is waiting on object B and thread 2 holds object B and is waiting on object A.

In all cases it is NOT safe to attempt to acquire a serialized object while IRQ or FIQ are disabled such as after calling SpinLockIRQ(or FIQ)()

Semaphore -

A counted serialization object that allows threads to proceed until the count reaches zero after which threads will be made to wait until the count is increased by another thread (or interrupt handler) calling signal.

Suitable for use by Interrupt handlers for signaling only if created with SEMAPHORE_FLAG_IRQ or FIQ (Interrupt handlers must not call wait).

Suitable for use on multiprocessor systems.

Access is serialized, the next thread to acquire the semaphore when it is signaled will be the thread that has been waiting longest (See also stolen wakeups below).

Usage:

Create/Destroy

Semaphores are created using SemaphoreCreate() and destroyed using SemaphoreDestroy(). With additional flags and options available by calling SemaphoreCreateEx(). The initial count of the Semaphore must be specified when calling create, in many usages the count will begin at zero but any value required by the application can be specified.

Wait/Signal

Threads consume the available count (or wait for count to be available) by calling SemaphoreWait() or SemaphoreWaitEx() if a timeout value is required.

Threads (or interrupt handlers) signal available count by calling SemaphoreSignal() or SemaphoreSignalEx() which allows increasing the count by values greater than one.

Lock Hierarchy -

Similar rules apply to all other serialized objects except that Semaphores support passing the flag SEMAPHORE_FLAG_IRQ (or FIQ) to SemaphoreCreateEx() so that signalling via the SemaphoreSignal() functions may be called from an interrupt handler.

Synchronizer -

A reader/writer lock for serializing multiple concurrent reads and single writes to data. Threads are placed on a wait list while waiting to acquire the lock.

Recursive (reader lock can be acquired multiple times by the same thread or by other threads/writer lock can be acquired multiple times by the same thread).

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Recommended for long held operations or holding during I/O operations.

Access is serialized, the next thread to obtain the lock when it is released will be the thread that has been waiting longest (See also stolen wakeups below).

Usage:

Create/Destroy

Synchronizers are created using SynchronizerCreate() or SynchronizerCreateEx() and destroyed using SynchronizerDestroy().

Lock/Unlock

Threads wanting read access to the protected data call SynchronizerReaderLock() and SynchronizerReaderUnlock() to obtain and release the lock. While one or more threads holds the reader lock no thread can obtain the writer lock.

A thread holding the reader lock can convert it to the writer lock by calling SynchronizerReaderConvert() but if any other thread is also holding the reader lock it will be placed in a wait list to wait until all threads have released the reader lock.

Threads wanting write access to the protected data call SynchronizerWriterLock() and SynchronizerWriterUnlock() to obtain and release the lock. While any thread holds the writer lock no thread can obtain the reader lock.

A thread holding the writer lock can convert it to the reader lock by calling SynchronizerWriterConvert(), because the writer lock is exclusive the thread will always obtain the reader lock immediately. All other threads currently waiting for the reader lock will also be released and given access.

Extended versions of the lock and convert functions for both reader and writer locks are available which allow specifying a timeout value to give up waiting after a specified time.

Lock Hierarchy -

The rules for Synchronizers are the same as those that apply to other serialized objects such as CriticalSection.

Condition -

A condition variable is used for coordinating synchronized access to resources by multiple threads. Condition variables are similar in concept to both Semaphores and Events but do not retain any internal state information so threads always wait until they are woken or the specified timeout interval expires.

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Access is serialized, the next thread released when a condition is woken will be the thread that has been waiting longest (See also stolen wakeups below).

Usage:

Create/Destroy

Conditions are created using ConditionCreate() and destroyed using ConditionDestroy().

Wait/Wake

Threads call ConditionWait() to begin waiting for the condition to be woken, additional versions of wait exist that allow releasing another lock before waiting and reacquiring it when the thread is woken after waiting.

These are ConditionWaitMutex(), ConditionWaitSynchronizer(), ConditionWaitCriticalSection() which apply to Mutex, Synchronizer and CriticalSection objects respectively.

Calling ConditionWake() will release one thread that is currently waiting for the condition, the ConditionWakeAll() function will release all threads waiting for the condition.

Lock Hierarchy -

The rules for Conditions are the same as those that apply to other serialized objects such as CriticalSection and Synchronizers.

Completion -

A completion is similar in concept to both condition variables and events but behaves differently to each of them. Completions are designed to be similar to the Linux synchronization object of the same name and provide a light weight mechanism for allowing one or more threads to wait for a signal that they can proceed. The completion differs from a condition variable because it maintains an internal state, once the state has been set (complete) threads pass through the completion without waiting (until the state is reset). This is similar to an event (see below) but in the case of a completion the state remains set indefinitely or until reset is called, a completion also allows explicitly releasing one thread at a time or all threads at once. More generally the event was created to model a behaviour that is similar to the same object in Windows and the completion models the Linux object instead.

Completions can use a counted state rather than a single state if they are created with COMPLETION_FLAG_COUNTED, this is to mimic the implementation of the Linux variation however there is a slight but important change in the way counted completions are implemented in Ultibo. The Linux completion sets the count to UMAX_INT / 2 on complete_all() which is documented as "effectively infinite". This is of course incorrect and seriously flawed because the count value is only set to a little over 2 billion, a long running application could easily consume this count with calls to wait_for_completion() and then the application would potentially fail without explanation.

To prevent this same fatal flaw the Ultibo implementation sets the count at LongWord(-1) on CompletionCompleteAll() and all other operations check for this value before incrementing or decrementing the count further. In this way the setting of complete all is genuinely infinite and will not fail on a long running application.

Suitable for use by Interrupt handlers to call complete only if created with COMPLETION_FLAG_IRQ or FIQ (Interrupt handlers must not call wait).

Suitable for use on multiprocessor systems.

Access is serialized, the next thread released when a completion is set will be the thread that has been waiting longest (See also stolen wakeups below).

Usage:

Create/Destroy

Completions are created using CompletionCreate() and destroyed using CompletionDestroy().

Wait/Reset/Complete

Threads call CompletionWait() to either wait for a completion to be set or proceed immediately if it is already set, for counted completions the count is decremented (if not -1) and if the count reaches 0 the state of the completion is reset. A CompletionTryWait() function is available to check the state and return immediately with an error if not set.

Threads (or interrupt handlers) set or reset the state of the completion by calling CompletionComplete(), CompletionReset() or CompletionCompleteAll().

See the header of each function for a detailed description of the behaviour in all applicable cases.

Lock Hierarchy -

The rules for Completions are the same as those that apply to other serialized objects such as CriticalSection and Synchronizers except that like Semaphores they may be signalled by interrupt handlers if the appropriate flags as passed to create.

Thread Handling

List -

A linked list designed to provide the wait list functionality for threads, each thread record includes a list element and the list elements include a thread handle to allow resolution in both directions. Lists are used by all serialized objects to hold threads in an ordered wait list that can be saftely manipulated in all scheduling states.

Lists are primarily intended to be used internally but are available for use by applications for appropriate cases.

Suitable for use by Interrupt handlers if created with appropriate flags.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Lists are created using ListCreate() or ListCreateEx() and destroyed using ListDestroy().

Add/Get/Insert/Remove

A complete set of functions exist for adding, removing and inserting elements into a list and for finding threads within a list.

See the header of each of the functions in the appropriate section below for more information.

Lock/Unlock

A pair of universal lock and unlock functions exist to acquire and release list locks with the appropriate IRQ (or FIQ) handling for the flags the list was created with. See ListLock() and ListUnlock() below for more information.

Queue -

An ordered linked list designed to provide scheduler queues for threads, each thread record includes a queue element and the queue elements include a thread handle to allow resolution in both directions.

Queues are primarily intended to be used internally but are available for use by applications for appropriate cases.

Suitable for use by Interrupt handlers if created with appropriate flags.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Queues are created using QueueCreate() or QueueCreateEx() and destroyed using QueueDestroy().

Enqueue/Dequeue/Insert/Delete/Increment/Decrement

A range of functions exist for adding, removing and inserting elements into a queue and for managing the elements within a queue.

See the header of each of the functions in the appropriate section below for more information.

Lock/Unlock

A pair of universal lock and unlock functions exist to acquire and release queue locks with the appropriate IRQ (or FIQ) handling for the flags the queue was created with. See QueueLock() and QueueUnlock() below for more information.

Message -

A simple record similar to the Windows MSG structure the TMessage contains fields whose purpose is opaque to the core of Ultibo and can be used for passing any type of information between threads or through other mechanisms.

No functions explicity exist to deal with messages, however they are used as the format for thread messages and are the record that is passed to ThreadSendMessage() and received from ThreadReceiveMessage(). Messages are also used as the record format for Messageslots (see below).

Thread -

Threads form the primary unit of code execution in Ultibo. It is not possible to create processes which run in their own protected address space, all threads run within the kernal and with full privilege so they can perform any operation required. The core of Ultibo always includes threading and multiple threads are created during the boot process to perform system critical functions.

The complete set of available thread functions are listed below and the header of each one includes more information including any important notes or restrictions to be aware of.

Additional Items

Messageslot -

The Messageslot allows multiple threads to wait on a single object for messages received from other sources. Where the thread message functions such as ThreadReceiveMessage() only allow a single thread to receive the message many threads can wait simultaneously on a Messageslot and will be woken in turn as new messages are received.

Suitable for use by Interrupt handlers for sending only if created with MESSAGESLOT_FLAG_IRQ or FIQ (Interrupt handlers must not call receive).

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Messageslots are created using MessageslotCreate() or MessageslotCreateEx() and destroyed using MessageslotDestroy().

Send/Receive

Threads wait for messages by calling MessageslotReceive() or MessageslotReceiveEx() to wait with a timeout.

Messages are sent using MessageslotSend() if the Messageslot is full and no more messages can be queued then an error will be returned instead of waiting for more space to be available.

Mailslot -

The Mailslot is similar to the Messageslot above and allows multiple threads to wait for messages to be received. Unlike a Messageslot where the sender will not wait if there is no space available to send, in a mailslot both the sender and receiver will wait for either available space or received messages. Mailslot messages are also an arbitrary pointer which means practically anything can be sent as long as the content is recognized by both the sender and receiver.

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Mailslots are created using MailslotCreate() and destroyed using MailslotDestroy().

Send/Receive

Threads wait for messages by calling MailslotReceive() or MailslotReceiveEx() to wait with a timeout.

Messages are sent using MailslotSend() or MailslotSendEx(), if the Mailslot is full and no more messages can be queued the sender will wait until more space becomes available.

Buffer -

A circular list which can hold blocks of memory, allocated records or any other type of pointer that needs to be acquired, used and later released as part of a data transfer or queuing mechanism. Buffers simply contain pointers so their content is completely up to the user to determine, the number of entries and the size of each entry must be specified when creating a Buffer.

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Buffers are created using BufferCreate() or BufferCreateEx() and destroyed using BufferDestroy().

Get/Free

The next available buffer entry is obtained by calling BufferGet() or BufferGetEx() to specify a timeout.

When the buffer is no longer required it can be returned to the list by calling BufferFree() and will be made available again.

During initialization of the Buffer all entries can be enumerated (in order to set initial values etc) by calling BufferIterate() however once the Buffer is in operation (and any entries have been obtained) it is not valid to call iterate again.

Event -

Events are a serialization object modelled on the Windows object of the same name, they can be set to allow threads to pass through or reset to force threads to wait. Events can also be pulsed to allow a only single waiting thread to pass.

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Events are created using EventCreate() or EventCreateEx() and destroyed using EventDestroy().

Wait/Set/Reset/Pulse

Threads call EventWait() to either wait for the Event to be set or pass through immediately if already set.

Calling EventSet(), EventReset() or EventPulse() changes the state of the Event and either allows threads to pass or require them to wait depending on the values defined when the Event was created.

See the description in the header of each function below for detailed information about the behaviour in each state.

Timer -

Timers provide a mechanism to request that a thread from the timer pool perform a specified function call in a certain number of milliseconds from the time the request was made. This can be a convenient way to retry an operation after a predetermined amount of time or to delay an operation until a certain amount of time has passed. Timers can be created as once off or recurring and can pass a supplied pointer to the called function.

Not suitable for use by Interrupt handlers.

Suitable for use on multiprocessor systems.

Usage:

Create/Destroy

Timers are created using TimerCreate() or TimerCreateEx() and destroyed using TimerDestroy().

Enable/Disable

Timers can be enabled or disabled using the TimerEnable() and TimerDisable() functions, calling TimerEnableEx() allows redefining some of the parameters specified during the call to TimerCreate() so an existing Timer can be reused for multiple purposes.

Worker -

The Worker thread pool provides a resource that can be used by system tasks and by applications as a convenient and reliable way to allocate work to other threads for asynchronous completion. The number of threads in the Worker pool can be dynamically increased or decreased to handle varying workloads. Using Worker threads to offload tasks can greatly simplify application design but does require attention be given to thread safety of data that is passed to Worker threads.

Not suitable for use by Interrupt handlers unless the WorkerScheduleIRQ or WorkerScheduleFIQ functions are used.

Suitable for use on multiprocessor systems.

Usage:

Schedule/Cancel

A task can be scheduled to a Worker thread by calling WorkerSchedule() or WorkerScheduleEx() depending on the parameters that need to be supplied. An already scheduled task can be cancelled by calling WorkerCancel() up until the point where the task is assigned to a Worker thread.

IRQ and FIQ Usage:

WorkerScheduleIRQ() and WorkerScheduleFIQ() are designed to allow calling from interrupt handlers (IRQ or FIQ) and provide deadlock prevention mechanisms.

WorkerScheduleIRQ() relies on the fact the scheduler will either be bound to an IRQ or an FIQ, in either case IRQ is disabled while the scheduler is active and in any calls with queue, list and thread locks that check for the scheduler assignment.

This means that an IRQ cannot occur when the scheduler is active or while it is blocked by a lock, calls to this function from a IRQ interrupt handler cannot deadlock.

WorkerScheduleFIQ() checks for the assignment of the scheduler, if the scheduler is bound to an FIQ then it proceeds as per the IRQ version because the FIQ cannot occur when the scheduler is active or while it is blocked by a lock. If the scheduler is bound to an IRQ then this function reverts to using the Tasker instead to transfer FIQ operations to an IRQ handler.

Both functions only support immediate scheduling of a one time task, delayed or repeating tasks cannot be scheduled.

It is safe to call either function from non interrupt code in order to allow shared code paths etc, however frequent calls to these functions from normal code can affect interrupt latency.

Tasker -

The Tasker is a mechanism for transferring work from a fast interrupt (FIQ) handler to an interrupt (IRQ) handler in order to allow access to certain operations which could otherwise deadlock. When the scheduler is bound to an IRQ then all queue, list and thread locks disable IRQ in order to prevent preemption by the scheduler, when IRQ is disabled then FIQ is still enabled and can preempt code that is holding an IRQ lock. If the FIQ handler attempts to access any of these locks then the handler can deadlock waiting for code that it had preempted.

In normal operation the clock interrupt is used to service the tasker list however it is board specific and could be assigned to either a different interrupt or a dedicated interrupt if required.

Suitable for use by Fast Interrupt handlers and Interrupt handlers (Not required for Interrupt handlers).

Suitable for use on multiprocessor systems.

Usage:

There are currently three Tasker functions avaiable, TaskerThreadSendMessage(), TaskerMessageslotSend() and TaskerSemaphoreSignal() which each perform the same function as their non Tasker equivalent.

The Tasker list is checked on each clock interrupt for tasks waiting to be triggered, the task is performed directly by the clock interrupt so the delay between request and trigger is no more than one clock interrupt interval.

Services

In addition to the various synchronization and serialization objects described above the following services are provided by this unit:

  ThreadManager
  Thread Creation and Stack allocation
  Thread Termination, Stack deallocation and cleanup
  Thread Functions (Sleep/Kill/Suspend/Resume etc)
  IRQ Thread (Boot process becomes the IRQ or FIQ Thread)
  FIQ Thread
  Idle Thread (An always ready thread which measures utilization)
  Main Thread (Main thread executes PASCALMAIN)
  Timer Threads (Pool of threads to service Timer requests)
  Worker Threads (Pool of threads to service Worker requests)
  Thread Scheduling, Allocation, Priority, Affinity and Migration

Stolen wakeups

Locking and synchronization types such as CriticalSection, Semaphore, Condition, Event, Messageslot and Mailslot use a wait queue internally to determine which thread has been waiting the longest. When a thread is removed from the wait queue so it can obtain the lock, semaphore, event etc there is a small window where the lock, semaphore or event may be acquired by another thread before the thread that was just woken from the wait queue. This is called a stolen wakeup and can happen in many systems including Windows and Linux, in some systems the caller is expected to check the state of a predicate value on return in order to detect a stolen wakeup. In Ultibo the code within the lock, semaphore, event etc functions automatically checks for a stolen wakeup and takes appropriate action to either return the thread to the wait queue or return with a timeout (where appropriate) so that the caller can respond accordingly.

In no case will a call to a locking or synchronization function fail due to a stolen wakeup, the worst case scenario is that a thread may wait longer than it should have (ie it is returned to the back of the queue) or it may return with a timeout before the specified timeout value has expired.

Constants

Type definitions

Spin entry

Mutex entry

Critical section entry

Semaphore entry

Synchronizer entry

Condition entry

Completion entry

List entry

List element

List handles

Queue entry

Queue element

Message list

Message

Thread entry

Thread snapshot

Messageslot entry

Mailslot entry

Buffer entry

Buffer item

Event entry

Timer list

Timer item

Timer entry

Worker request

Tasker list

Tasker task

Tasker thread send message

Tasker messageslot send

Tasker semaphore signal

Thread info

CPU start

Primary initialization

Scheduler initialization

Scheduler start

Secondary initialization

Secondary boot

Spin lock

Spin unlock

Spin lock IRQ

Spin unlock IRQ

Spin lock FIQ

Spin unlock FIQ

Spin lock IRQ/FIQ

Spin unlock IRQ/FIQ

Spin check IRQ

Spin check FIQ

Spin exchange IRQ

Spin exchange FIQ

Spin mask exchange

Mutex lock

Mutex unlock

Mutex try lock

Critical section lock

Critical section lock ex

Critical section unlock

Critical section try lock

Semaphore wait

Semaphore wait ex

Semaphore signal

Synchronizer lock

Synchronizer lock ex

Synchronizer unlock

Synchronizer convert

Synchronizer convert ex

Condition wait

Condition wait mutex

Condition wait synchronizer

Condition wait critical section

Condition wake

Condition wake all

Completion wait

Completion try wait

Completion reset

Completion complete

Completion complete all

Messageslot send

Messageslot receive

Messageslot receive ex

Mailslot send

Mailslot send ex

Mailslot receive

Mailslot receive ex

Buffer get

Buffer get ex

Buffer free

Buffer iterate

Event wait

Event wait ex

Event set

Event reset

Event pulse

Timer enable

Timer enable ex

Timer disable

Timer check

Timer trigger

Tasker check

Tasker trigger

Thread get current

Thread set current

Thread start

Thread end

Scheduler check

Scheduler wakeup

Scheduler expire

Scheduler switch

Scheduler select

Scheduler reschedule

Scheduler migration enable

Scheduler migration disable

Scheduler preempt enable

Scheduler preempt disable

Scheduler allocation enable

Scheduler allocation disable

Thread setup stack

Public variables

Thread logging

Scheduler variables

Scheduler debug

Lock debug

Spin debug

Mutex debug

Heap manager variables

RTL thread manager variables

Initialization handlers

SpinLock/Unlock handlers

MutexLock/Unlock handlers

CriticalSection Lock/Unlock/TryLock handlers

Semaphore Wait/Signal handlers

Synchronizer Reader/WriterLock/Unlock handlers

Condition Wait/Wake/WakeAll Handlers

Completion Wait/TryWait/Reset/Complete/CompleteAll Handlers

Messageslot send and receive handlers

Mailslot send and receive handlers

Buffer Get/GetEx/Free handlers

Event Wait/Set/Reset/Pulse handlers

Timer Enable/Disable/Check/Trigger handlers

Tasker Check/Trigger handlers

Thread Get/SetCurrent handlers

Scheduler Check/Wakeup/Expire/Select/Switch handlers

Thread SetupStack handlers

Function declarations

Initialization functions

procedure LocksInit;

procedure ThreadsInit;

procedure PrimaryInit;

procedure SchedulerInit;

procedure SchedulerStart(CPUID:LongWord);

procedure SecondaryInit;

procedure SecondaryBoot(CPUID:LongWord);

procedure SecondaryStart(CPUID:LongWord);

function IRQExecute(Parameter:Pointer):PtrInt;

function FIQExecute(Parameter:Pointer):PtrInt;

function SWIExecute(Parameter:Pointer):PtrInt;

function IdleExecute(Parameter:Pointer):PtrInt;

function MainExecute(Parameter:Pointer):PtrInt;

function TimerExecute(Parameter:Pointer):PtrInt;

function WorkerExecute(Parameter:Pointer):PtrInt;

function TimerPriorityExecute(Parameter:Pointer):PtrInt;

function WorkerPriorityExecute(Parameter:Pointer):PtrInt;

function IdleCalibrate:LongWord;

Spin functions

function SpinCreate:TSpinHandle;

function SpinCreateEx(InitialOwner:Boolean):TSpinHandle;

function SpinDestroy(Spin:TSpinHandle):LongWord;

function SpinOwner(Spin:TSpinHandle):TThreadHandle;

function SpinLock(Spin:TSpinHandle):LongWord;

function SpinUnlock(Spin:TSpinHandle):LongWord;

function SpinLockIRQ(Spin:TSpinHandle):LongWord;

function SpinUnlockIRQ(Spin:TSpinHandle):LongWord;

function SpinLockFIQ(Spin:TSpinHandle):LongWord;

function SpinUnlockFIQ(Spin:TSpinHandle):LongWord;

function SpinLockIRQFIQ(Spin:TSpinHandle):LongWord;

function SpinUnlockIRQFIQ(Spin:TSpinHandle):LongWord;

function SpinLockPreempt(Spin:TSpinHandle):LongWord;

function SpinUnlockPreempt(Spin:TSpinHandle):LongWord;

function SpinCheckIRQ(Spin:TSpinHandle):Boolean;

function SpinCheckFIQ(Spin:TSpinHandle):Boolean;

function SpinExchangeIRQ(Spin1,Spin2:TSpinHandle):LongWord;

function SpinExchangeFIQ(Spin1,Spin2:TSpinHandle):LongWord;

function SpinLockDefault(SpinEntry:PSpinEntry):LongWord;

function SpinUnlockDefault(SpinEntry:PSpinEntry):LongWord;

function SpinLockIRQDefault(SpinEntry:PSpinEntry):LongWord;

function SpinUnlockIRQDefault(SpinEntry:PSpinEntry):LongWord;

function SpinLockFIQDefault(SpinEntry:PSpinEntry):LongWord;

function SpinUnlockFIQDefault(SpinEntry:PSpinEntry):LongWord;

function SpinLockIRQFIQDefault(SpinEntry:PSpinEntry):LongWord;

function SpinUnlockIRQFIQDefault(SpinEntry:PSpinEntry):LongWord;

Mutex functions

function MutexCreate:TMutexHandle;

function MutexCreateEx(InitialOwner:Boolean; SpinCount:LongWord; Flags:LongWord):TMutexHandle;

function MutexDestroy(Mutex:TMutexHandle):LongWord;

function MutexFlags(Mutex:TMutexHandle):LongWord;

function MutexCount(Mutex:TMutexHandle):LongWord;

function MutexOwner(Mutex:TMutexHandle):TThreadHandle;

function MutexLock(Mutex:TMutexHandle):LongWord;

function MutexUnlock(Mutex:TMutexHandle):LongWord;

function MutexTryLock(Mutex:TMutexHandle):LongWord;

function MutexLockDefault(MutexEntry:PMutexEntry):LongWord;

function MutexUnlockDefault(MutexEntry:PMutexEntry):LongWord;

function MutexTryLockDefault(MutexEntry:PMutexEntry):LongWord;

Critical section functions

function CriticalSectionCreate:TCriticalSectionHandle;

function CriticalSectionCreateEx(InitialOwner:Boolean; SpinCount:LongWord):TCriticalSectionHandle;

function CriticalSectionDestroy(CriticalSection:TCriticalSectionHandle):LongWord;

function CriticalSectionCount(CriticalSection:TCriticalSectionHandle):LongWord;

function CriticalSectionOwner(CriticalSection:TCriticalSectionHandle):TThreadHandle;

function CriticalSectionSetSpinCount(CriticalSection:TCriticalSectionHandle; SpinCount:LongWord):LongWord;

function CriticalSectionLock(CriticalSection:TCriticalSectionHandle):LongWord;

function CriticalSectionLockEx(CriticalSection:TCriticalSectionHandle; Timeout:LongWord):LongWord;

function CriticalSectionUnlock(CriticalSection:TCriticalSectionHandle):LongWord;

function CriticalSectionTryLock(CriticalSection:TCriticalSectionHandle):LongWord;

Semaphore functions

function SemaphoreCreate(Count:LongWord):TSemaphoreHandle;

function SemaphoreCreateEx(Count,Maximum:LongWord; Flags:LongWord):TSemaphoreHandle;

function SemaphoreDestroy(Semaphore:TSemaphoreHandle):LongWord;

function SemaphoreCount(Semaphore:TSemaphoreHandle):LongWord;

function SemaphoreWait(Semaphore:TSemaphoreHandle):LongWord;

function SemaphoreWaitEx(Semaphore:TSemaphoreHandle; Timeout:LongWord):LongWord;

function SemaphoreSignal(Semaphore:TSemaphoreHandle):LongWord;

function SemaphoreSignalEx(Semaphore:TSemaphoreHandle; Count:LongWord; Previous:PLongWord):LongWord;

Synchronizer functions

function SynchronizerCreate:TSynchronizerHandle;

function SynchronizerCreateEx(InitialReader,InitialWriter:Boolean):TSynchronizerHandle;

function SynchronizerDestroy(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerReaderCount(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerReaderLast(Synchronizer:TSynchronizerHandle):TThreadHandle;

function SynchronizerReaderLock(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerReaderLockEx(Synchronizer:TSynchronizerHandle; Timeout:LongWord):LongWord;

function SynchronizerReaderUnlock(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerReaderConvert(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerReaderConvertEx(Synchronizer:TSynchronizerHandle; Timeout:LongWord):LongWord;

function SynchronizerWriterCount(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerWriterOwner(Synchronizer:TSynchronizerHandle):TThreadHandle;

function SynchronizerWriterLock(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerWriterLockEx(Synchronizer:TSynchronizerHandle; Timeout:LongWord):LongWord;

function SynchronizerWriterUnlock(Synchronizer:TSynchronizerHandle):LongWord;

function SynchronizerWriterConvert(Synchronizer:TSynchronizerHandle):LongWord;

Condition functions

function ConditionCreate:TConditionHandle;

function ConditionDestroy(Condition:TConditionHandle):LongWord;

function ConditionWait(Condition:TConditionHandle; Timeout:LongWord = INFINITE):LongWord;

function ConditionWaitMutex(Condition:TConditionHandle; Mutex:TMutexHandle; Timeout:LongWord = INFINITE):LongWord;

function ConditionWaitSynchronizer(Condition:TConditionHandle; Synchronizer:TSynchronizerHandle; Flags:LongWord; Timeout:LongWord = INFINITE):LongWord;

function ConditionWaitCriticalSection(Condition:TConditionHandle; CriticalSection:TCriticalSectionHandle; Timeout:LongWord = INFINITE):LongWord;

function ConditionWake(Condition:TConditionHandle):LongWord;

function ConditionWakeAll(Condition:TConditionHandle):LongWord;

Completion functions

function CompletionLock(Completion:PCompletionEntry):LongWord;

function CompletionUnlock(Completion:PCompletionEntry):LongWord;

function CompletionCreate(Flags:LongWord = COMPLETION_FLAG_NONE):TCompletionHandle;

function CompletionDestroy(Completion:TCompletionHandle):LongWord;

function CompletionState(Completion:TCompletionHandle):LongWord;

function CompletionWait(Completion:TCompletionHandle; Timeout:LongWord = INFINITE):LongWord;

function CompletionTryWait(Completion:TCompletionHandle):LongWord;

function CompletionReset(Completion:TCompletionHandle):LongWord;

function CompletionComplete(Completion:TCompletionHandle):LongWord;

function CompletionCompleteAll(Completion:TCompletionHandle):LongWord;

List functions

function ListCreate:TListHandle;

function ListCreateEx(ListType:LongWord; Flags:LongWord):TListHandle;

function ListDestroy(List:TListHandle):LongWord;

function ListCount(List:TListHandle):LongWord;

function ListAddFirst(List:TListHandle; Element:PListElement):LongWord;

function ListAddLast(List:TListHandle; Element:PListElement):LongWord;

function ListGetThread(List:TListHandle; Thread:TThreadHandle):PListElement;

function ListGetFirst(List:TListHandle):PListElement;

function ListGetFirstEx(List:TListHandle; Remove:Boolean):PListElement;

function ListGetLast(List:TListHandle):PListElement;

function ListGetLastEx(List:TListHandle; Remove:Boolean):PListElement;

function ListInsert(List:TListHandle; Previous,Element:PListElement):LongWord;

function ListRemove(List:TListHandle; Element:PListElement):LongWord;

function ListIsEmpty(List:TListHandle):Boolean;

function ListNotEmpty(List:TListHandle):Boolean;

function ListLock(List:TListHandle):LongWord;

function ListUnlock(List:TListHandle):LongWord;

function ListLock(List:TListHandle):LongWord;

function ListUnlock(List:TListHandle):LongWord;

Queue functions

function QueueCreate:TQueueHandle;

function QueueCreateEx(QueueType:LongWord; Flags:LongWord):TQueueHandle;

function QueueDestroy(Queue:TQueueHandle):LongWord;

function QueueCount(Queue:TQueueHandle):LongWord;

function QueueEnqueue(Queue:TQueueHandle; Thread:TThreadHandle):LongWord;

function QueueDequeue(Queue:TQueueHandle):TThreadHandle;

function QueueFirstKey(Queue:TQueueHandle):Integer;

function QueueLastKey(Queue:TQueueHandle):Integer;

function QueueInsertKey(Queue:TQueueHandle; Thread:TThreadHandle; Key:Integer):LongWord;

function QueueDeleteKey(Queue:TQueueHandle; Thread:TThreadHandle):LongWord;

function QueueIncrementKey(Queue:TQueueHandle):Integer;

function QueueDecrementKey(Queue:TQueueHandle):Integer;

function QueueIsEmpty(Queue:TQueueHandle):Boolean;

function QueueNotEmpty(Queue:TQueueHandle):Boolean;

function QueueLock(Queue:TQueueHandle):LongWord;

function QueueUnlock(Queue:TQueueHandle):LongWord;

Thread functions

function ThreadCreate(StartProc:TThreadStart; StackSize,Priority:LongWord; Name:PChar; Parameter:Pointer):TThreadHandle;

function ThreadCreateEx(StartProc:TThreadStart; StackSize,Priority,Affinity,CPU:LongWord; Name:PChar; Parameter:Pointer):TThreadHandle;

function ThreadDestroy(Thread:TThreadHandle):LongWord;

function ThreadGetCurrent:TThreadHandle; inline;

function ThreadSetCurrent(Thread:TThreadHandle):LongWord; inline;

function ThreadGetName(Thread:TThreadHandle):String;

function ThreadSetName(Thread:TThreadHandle; const Name:String):LongWord;

function ThreadGetCPU(Thread:TThreadHandle):LongWord;

function ThreadSetCPU(Thread:TThreadHandle; CPU:LongWord):LongWord;

function ThreadGetState(Thread:TThreadHandle):LongWord;

function ThreadGetFlags(Thread:TThreadHandle):LongWord;

function ThreadSetFlags(Thread:TThreadHandle; Flags:LongWord):LongWord;

function ThreadAddFlags(Thread:TThreadHandle; Flags:LongWord):LongWord;

function ThreadRemoveFlags(Thread:TThreadHandle; Flags:LongWord):LongWord;

function ThreadGetLocale(Thread:TThreadHandle):LCID;

function ThreadSetLocale(Thread:TThreadHandle; Locale:LCID):LongWord;

function ThreadGetTimes(Thread:TThreadHandle; var CreateTime,ExitTime,KernelTime:Int64):LongWord;

function ThreadGetSwitchCount(Thread:TThreadHandle; var SwitchCount:Int64):LongWord;