Go to the first, previous, next, last section, table of contents.
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.
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.
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.
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 specifices the particular operation that should be applied to this restartable atomic sequence. Possible values for flavor can be:
TASK_RAS_CONTROL_PURGE_ALL
TASK_RAS_CONTROL_PURGE_ONE
TASK_RAS_CONTROL_PURGE_ALL_AND_INSTALL_ONE
TASK_RAS_CONTROL_INSTALL_ONE
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.
Go to the first, previous, next, last section, table of contents.