— Function: kern_return_t task_suspend (task_t target_task)

The function task_suspend increments the task's suspend count and stops all threads in the task. As long as the suspend count is positive newly created threads will not run. This call does not return until all threads are suspended.

The count may become greater than one, with the effect that it will take more than one resume call to restart the task.

The function returns KERN_SUCCESS if the task has been suspended and KERN_INVALID_ARGUMENT if target_task is not a task.

— Function: kern_return_t task_resume (task_t target_task)

The function task_resume decrements the task's suspend count. If it becomes zero, all threads with zero suspend counts in the task are resumed. The count may not become negative.

The function returns KERN_SUCCESS if the task has been resumed, KERN_FAILURE if the suspend count is already at zero and KERN_INVALID_ARGUMENT if target_task is not a task.

— Function: kern_return_t task_priority (task_t task, int priority, boolean_t change_threads)

The priority of a task is used only for creation of new threads; a new thread's priority is set to the enclosing task's priority. task_priority changes this task priority. It also sets the priorities of all threads in the task to this new priority if change_threads is TRUE. Existing threads are not affected otherwise. If this priority change violates the maximum priority of some threads, as many threads as possible will be changed and an error code will be returned.

The function returns KERN_SUCCESS if the call succeeded, KERN_INVALID_ARGUMENT if task is not a task, or priority is not a valid priority and KERN_FAILURE if change_threads was TRUE and the attempt to change the priority of at least one existing thread failed because the new priority would have exceeded that thread's maximum priority.

— Function: kern_return_t task_ras_control (task_t target_task, vm_address_t start_pc, vm_address_t end_pc, int flavor)

The function task_ras_control manipulates a task's set of restartable atomic sequences. If a sequence is installed, and any thread in the task is preempted within the range [start_pc,end_pc], then the thread is resumed at start_pc. This enables applications to build atomic sequences which, when executed to completion, will have executed atomically. Restartable atomic sequences are intended to be used on systems that do not have hardware support for low-overhead atomic primitives.

As a thread can be rolled-back, the code in the sequence should have no side effects other than a final store at end_pc. The kernel does not guarantee that the sequence is restartable. It assumes the application knows what it's doing.

A task may have a finite number of atomic sequences that is defined at compile time.

The flavor specifies the particular operation that should be applied to this restartable atomic sequence. Possible values for flavor can be:

TASK_RAS_CONTROL_PURGE_ALL

Remove all registered sequences for this task.

TASK_RAS_CONTROL_PURGE_ONE

Remove the named registered sequence for this task.

TASK_RAS_CONTROL_PURGE_ALL_AND_INSTALL_ONE

Atomically remove all registered sequences and install the named sequence.

TASK_RAS_CONTROL_INSTALL_ONE

Install this sequence.

The function returns KERN_SUCCESS if the operation has been performed, KERN_INVALID_ADDRESS if the start_pc or end_pc values are not a valid address for the requested operation (for example, it is invalid to purge a sequence that has not been registered), KERN_RESOURCE_SHORTAGE if an attempt was made to install more restartable atomic sequences for a task than can be supported by the kernel, KERN_INVALID_VALUE if a bad flavor was specified, KERN_INVALID_ARGUMENT if target_task is not a task and KERN_FAILURE if the call is not not supported on this configuration.