Unit Threads

Return to Unit Reference

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 or reset 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 safely 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 kernel 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 five Tasker functions available, TaskerThreadSendMessage(), TaskerMessageslotSend(), TaskerSemaphoreSignal(), TaskerCompletionReset() and TaskerCompletionComplete() 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.

`LOCK_FLAG_NONE = $00000000;`
`LOCK_FLAG_IRQ = $00000001;`
`LOCK_FLAG_FIQ = $00000002;`
`LOCK_FLAG_IRQFIQ = $00000004;`

`MUTEX_FLAG_NONE = $00000000;`
`MUTEX_FLAG_RECURSIVE = $00000001;`	Mutex can be locked multiple times by the same thread if set (Must be unlocked the same number of times)
`MUTEX_FLAG_ERRORCHECK = $00000002;`	Mutex will perform a deadlock check if set, will return with an error if already owned by the same thread (and not recursive)

`CRITICAL_SECTION_STATE_UNLOCKED = 0;`
`CRITICAL_SECTION_STATE_LOCKED = 1;`

`SEMAPHORE_FLAG_NONE = LOCK_FLAG_NONE;`
`SEMAPHORE_FLAG_IRQ = LOCK_FLAG_IRQ;`
`SEMAPHORE_FLAG_FIQ = LOCK_FLAG_FIQ;`
`SEMAPHORE_FLAG_IRQFIQ = LOCK_FLAG_IRQFIQ;`

`SYNCHRONIZER_STATE_UNLOCKED = 0;`
`SYNCHRONIZER_STATE_READER_LOCKED = 1;`
`SYNCHRONIZER_STATE_WRITER_LOCKED = 2;`

`SYNCHRONIZER_FLAG_NONE = $00000000;`
`SYNCHRONIZER_FLAG_READ_PRIORITY = $00000001;`	Synchronizer prioritises readers over writers
`SYNCHRONIZER_FLAG_WRITE_PRIORITY = $00000002;`	Synchronizer prioritises writers over readers

`CONDITION_LOCK_FLAG_NONE = $00000000;`
`CONDITION_LOCK_FLAG_WRITER = $00000001;`	Condition should release and acquire the writer lock on a Synchronizer when ConditionWaitSynchronizer is called (otherwise release and acquire the reader lock)

`COMPLETION_STATE_RESET = 0;`
`COMPLETION_STATE_COMPLETE = 1;`

`COMPLETION_FLAG_NONE = LOCK_FLAG_NONE;`
`COMPLETION_FLAG_IRQ = LOCK_FLAG_IRQ;`	Disable IRQ during completion operations (Wait/Reset/Complete)
`COMPLETION_FLAG_FIQ = LOCK_FLAG_FIQ;`	Disable FIQ during completion operations (Wait/Reset/Complete)
`COMPLETION_FLAG_IRQFIQ = LOCK_FLAG_IRQFIQ;`	Disable IRQ and FIQ during completion operations (Wait/Reset/Complete)
`COMPLETION_FLAG_COUNTED = $00000008;`	Use a counted value instead of a single state (Affects behaviour of Wait and Complete)

`LIST_TYPE_NOT_SPECIFIED = 0;`	A generic thread list without a specific purpose
`LIST_TYPE_WAIT_SECTION = 1;`	A Critical Section Wait List
`LIST_TYPE_WAIT_SEMAPHORE = 2;`	A Semaphore Wait List
`LIST_TYPE_WAIT_SYNCHRONIZER = 3;`	A Synchronizer Wait List
`LIST_TYPE_WAIT_CONDITION = 4;`	A Condition Wait List
`LIST_TYPE_WAIT_COMPLETION = 5;`	A Condition Wait List
`LIST_TYPE_WAIT_EVENT = 6;`	An Event Wait List
`LIST_TYPE_WAIT_THREAD = 7;`	A Thread Wait List
`LIST_TYPE_WAIT_MESSAGESLOT = 8;`	A Messageslot Wait List
`LIST_TYPE_WAIT_OTHER = 9;`	Another type of Wait List (Suitable for passing to ThreadWait/ThreadWaitEx/ThreadWaitMultiple/ThreadRelease)

`SPIN_STATE_UNLOCKED = 0;`
`SPIN_STATE_LOCKED = 1;`

`MUTEX_STATE_UNLOCKED = 0;`
`MUTEX_STATE_LOCKED = 1;`

`LIST_FLAG_NONE = LOCK_FLAG_NONE;`
`LIST_FLAG_IRQ = LOCK_FLAG_IRQ;`
`LIST_FLAG_FIQ = LOCK_FLAG_FIQ;`
`LIST_FLAG_IRQFIQ = LOCK_FLAG_IRQFIQ;`

`QUEUE_TYPE_NOT_SPECIFIED = 0;`	A generic thread queue without a specific purpose
`QUEUE_TYPE_SCHEDULE_SLEEP = 1;`	A Scheduler Sleep Queue
`QUEUE_TYPE_SCHEDULE_TIMEOUT = 2;`	A Scheduler Timeout Queue
`QUEUE_TYPE_SCHEDULE_TERMINATION = 3;`	A Scheduler Termination Queue (Threads are placed on termination queue when they exit or are terminated)
`QUEUE_TYPE_SCHEDULE_NONE = 4;`	A Scheduler No Priority Queue (Only used for IRQ/FIQ threads which are never selected for scheduling)
`QUEUE_TYPE_SCHEDULE_IDLE = 5;`	A Scheduler Idle Priority Queue
`QUEUE_TYPE_SCHEDULE_LOWEST = 6;`	A Scheduler Lowest Priority Queue
`QUEUE_TYPE_SCHEDULE_LOWER = 7;`	A Scheduler Lower Priority Queue
`QUEUE_TYPE_SCHEDULE_NORMAL = 8;`	A Scheduler Normal Priority Queue
`QUEUE_TYPE_SCHEDULE_HIGHER = 9;`	A Scheduler Higher Priority Queue
`QUEUE_TYPE_SCHEDULE_HIGHEST = 10;`	A Scheduler Highest Priority Queue
`QUEUE_TYPE_SCHEDULE_CRITICAL = 11;`	A Scheduler Critical Priority Queue

`NONE = LOCK_FLAG_NONE;`
`QUEUE_FLAG_IRQ = LOCK_FLAG_IRQ;`
`QUEUE_FLAG_FIQ = LOCK_FLAG_FIQ;`
`QUEUE_FLAG_IRQFIQ = LOCK_FLAG_IRQFIQ;`
`QUEUE_FLAG_DESCENDING = $00000008;`
`QUEUE_FLAG_DELTA = $00000010;`

`QUEUE_KEY_NONE = Integer($7FFFFFFF);`	Null key value returned from an empty Queue
`QUEUE_KEY_MAX = Integer($7FFFFFFE);`	Max key that can be ordered in a Queue
`QUEUE_KEY_MIN = Integer($80000000);`	Min key that can be ordered in a Queue

`THREAD_TYPE_NORMAL = 0;`	A Normal thread (No special case handling)
`THREAD_TYPE_IDLE = 1;`	An Idle thread (Used to calculate ultilization and provide an always ready thread)
`THREAD_TYPE_IRQ = 2;`	An IRQ thread (Used by the IRQ handler during interrupt time)
`THREAD_TYPE_FIQ = 3;`	An FIQ thread (Used by the FIQ handler during interrupt time)
`THREAD_TYPE_SWI = 4;`	A Software Interrupt (SWI) thread (Used by the SWI handler during a system call)

`THREAD_FLAG_NONE = $00000000;`
`THREAD_FLAG_PERSIST = $00000001;`	If set thread handle will persist until explicitly destroyed (Otherwise destroyed after termination quantum has elapsed)
`THREAD_FLAG_CANCELLED = $00000002;`	Indicates that thread has been cancelled, for support of external thread APIs eg. pThreads (Not used internally by Ultibo)
`THREAD_FLAG_CANCEL_DISABLE = $00000004;`	Indicates that thread cancellation is disabled for a thread, for support of external thread APIs eg. pThreads (Not used internally by Ultibo)
`THREAD_FLAG_CANCEL_ASYNCHRONOUS = $00000008;`	Indicates that asynchronous thread cancellation is enabled for a thread, for support of external thread APIs eg. pThreads (Not used internally by Ultibo)

`THREAD_FLAG_INTERNAL = THREAD_FLAG_NONE + $80000000;`	Note: Temporary value to avoid warning

`THREAD_STATE_RUNNING = 1;`	Thread is currently running
`THREAD_STATE_READY = 2;`	Thread is on ready queue
`THREAD_STATE_SLEEP = 3;`	Thread is sleeping
`THREAD_STATE_SUSPENDED = 4;`	Thread is suspended
`THREAD_STATE_WAIT = 5;`	Thread is on a wait list
`THREAD_STATE_WAIT_TIMEOUT = 6;`	Thread is on a wait list with timeout
`THREAD_STATE_RECEIVE = 7;`	Thread is waiting to receive a message
`THREAD_STATE_RECEIVE_TIMEOUT = 8;`	Thread is waiting to receive a message with timeout
`THREAD_STATE_HALTED = 9;`	Thread has been halted (Due to an unhandled exception etc)
`THREAD_STATE_TERMINATED = 10;`	Thread has been terminated

`THREAD_PRIORITY_NONE = 0;`	Only used for IRQ/FIQ threads which are never selected for scheduling
`THREAD_PRIORITY_IDLE = 1;`
`THREAD_PRIORITY_LOWEST = 2;`
`THREAD_PRIORITY_LOWER = 3;`
`THREAD_PRIORITY_NORMAL = 4;`
`THREAD_PRIORITY_HIGHER = 5;`
`THREAD_PRIORITY_HIGHEST = 6;`
`THREAD_PRIORITY_CRITICAL = 7;`

`THREAD_PRIORITY_DEFAULT = THREAD_PRIORITY_NORMAL;`	Default thread priority
`THREAD_PRIORITY_MINIMUM = THREAD_PRIORITY_IDLE;`	Minimum thread priority
`THREAD_PRIORITY_MAXIMUM = THREAD_PRIORITY_CRITICAL;`	Maximum thread priority
`THREAD_PRIORITY_COUNT = THREAD_PRIORITY_MAXIMUM + 1;`	Number of thread priority levels

Additional priority aliases for compatibility
`THREAD_PRIORITY_BELOW_NORMAL = THREAD_PRIORITY_LOWER;`
`THREAD_PRIORITY_ABOVE_NORMAL = THREAD_PRIORITY_HIGHER;`
`THREAD_PRIORITY_TIME_CRITICAL = THREAD_PRIORITY_CRITICAL;`

`THREAD_NAME_LENGTH = SIZE_64;`	Length of thread name

`IRQ_THREAD_NAME = 'IRQ';`
`FIQ_THREAD_NAME = 'FIQ';`
`SWI_THREAD_NAME = 'SWI';`
`IDLE_THREAD_NAME = 'Idle';`
`MAIN_THREAD_NAME = 'Main';`
`TIMER_THREAD_NAME = 'Timer';`
`WORKER_THREAD_NAME = 'Worker';`
`TIMER_PRIORITY_THREAD_NAME = 'Priority Timer';`
`WORKER_PRIORITY_THREAD_NAME = 'Priority Worker';`
`RTL_THREAD_NAME = 'RTL Thread';`

`TIMER_THREAD_PRIORITY = THREAD_PRIORITY_NORMAL;`
`WORKER_THREAD_PRIORITY = THREAD_PRIORITY_NORMAL;`
`TIMER_PRIORITY_THREAD_PRIORITY = THREAD_PRIORITY_HIGHEST;`
`WORKER_PRIORITY_THREAD_PRIORITY = THREAD_PRIORITY_HIGHER;`

`THREAD_CREATE_NONE = $00000000;`
`THREAD_CREATE_SUSPENDED = $00000004;`

`THREAD_TLS_FREE = $00000000;`
`THREAD_TLS_USED = $00000001;`
`THREAD_TLS_INVALID = $FFFFFFFF;`

`THREAD_TLS_MAXIMUM = SIZE_64;`	The maximum number TLS index slots available

Unit Threads

Contents

Description

Constants

Type definitions

Public variables

Function declarations

Navigation menu

Search

`THREAD_TLS_FLAG_NONE = $00000000;`
`THREAD_TLS_FLAG_FREE = $00000001;`	If set then pointer in thread TLS index will be freed on ThreadReleaseTlsIndex or ThreadDestroy

`MESSAGESLOT_FLAG_NONE = LOCK_FLAG_NONE;`
`MESSAGESLOT_FLAG_IRQ = LOCK_FLAG_IRQ;`
`MESSAGESLOT_FLAG_FIQ = LOCK_FLAG_FIQ;`
`MESSAGESLOT_FLAG_IRQFIQ = LOCK_FLAG_IRQFIQ;`

`BUFFER_FLAG_NONE = $00000000;`
`BUFFER_FLAG_SHARED = $00000001;`	If set the buffer memory (Not the buffer entry itself) is allocated from shared memory

`EVENT_FLAG_NONE = $00000000;`
`EVENT_FLAG_INITIAL_STATE = $00000001;`
`EVENT_FLAG_MANUAL_RESET = $00000002;`

`TIMER_FLAG_NONE = $00000000;`
`TIMER_FLAG_RESCHEDULE = $00000001;`	Timer should be rescheduled each time the event completes
`TIMER_FLAG_IMMEDIATE = $00000002;`	Timer event should be executed immediately and then each interval milliseconds
`TIMER_FLAG_WORKER = $00000004;`	Timer event should be executed by a worker thread instead of a timer thread
`TIMER_FLAG_PRIORITY = $00000008;`	Timer event should be executed by a priority timer thread

`TIMER_KEY_NONE = Integer($7FFFFFFF);`	Null key value returned from an empty Timer list
`TIMER_KEY_MAX = Integer($7FFFFFFE);`	Max key that can be ordered in a Timer list
`TIMER_KEY_MIN = Integer($80000000);`	Min key that can be ordered in a Timer list

`WORKER_FLAG_NONE = $00000000;`
`WORKER_FLAG_RESCHEDULE = $00000001;`	Worker task should be rescheduled each time the task completes
`WORKER_FLAG_IMMEDIATE = $00000002;`	Worker task should be executed immediately and then each interval milliseconds
`WORKER_FLAG_CANCEL = $00000004;`	Internal flag to indicate the worker task should be cancelled next time the interval expires
`WORKER_FLAG_NOFREE = $00000008;`	Internal flag to tell worker execute not to free the worker request when it is completed
`WORKER_FLAG_TERMINATE = $00000010;`	Internal flag to tell worker execute to terminate the worker thread
`WORKER_FLAG_IRQ = $00000020;`	Internal flag to tell worker execute to free IRQ memory when the request is completed
`WORKER_FLAG_FIQ = $00000040;`	Internal flag to tell worker execute to free FIQ memory when the request is completed
`WORKER_FLAG_PRIORITY = $00000080;`	Worker task should be executed by a priority worker thread

`WORKER_FLAG_INTERNAL = WORKER_FLAG_CANCEL or WORKER_FLAG_NOFREE or WORKER_FLAG_TERMINATE or WORKER_FLAG_IRQ or WORKER_FLAG_FIQ;`	Internal only flags

`WORKER_FLAG_EXCLUDED_IRQ = WORKER_FLAG_RESCHEDULE or WORKER_FLAG_IMMEDIATE;`	Excluded flags
`WORKER_FLAG_EXCLUDED_FIQ = WORKER_FLAG_RESCHEDULE or WORKER_FLAG_IMMEDIATE;`	Excluded flags

`TASKER_TASK_THREADSENDMESSAGE = 1;`	Perform a ThreadSendMessage() function using the tasker list
`TASKER_TASK_MESSAGESLOTSEND = 2;`	Perform a MessageslotSend() function using the tasker list
`TASKER_TASK_SEMAPHORESIGNAL = 3;`	Perform a SemaphoreSignal() function using the tasker list
`TASKER_TASK_COMPLETIONRESET = 4;`	Perform a CompletionReset() function using the tasker list
`TASKER_TASK_COMPLETIONCOMPLETE = 5;`	Perform a CompletionComplete() or CompletionCompleteAll() function using the tasker list

`SCHEDULER_MIGRATION_DISABLED = 0;`
`SCHEDULER_MIGRATION_ENABLED = 1;`

`SCHEDULER_PREEMPT_DISABLED = 0;`
`SCHEDULER_PREEMPT_ENABLED = 1;`