xsh_chap02_09.html

IEEE 1003.1-2003, Single Unix Specification v3

<li>
<p><sup>[<a href="javascript:open_code('TMO')">TMO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
It returns successfully from <a href="../functions/pthread_mutex_timedlock.html"><i>pthread_mutex_timedlock</i>()</a> with <i>m</i>
as the mutex argument. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
</li>

<li>
<p>It returns (successfully or not) from <a href="../functions/pthread_cond_wait.html"><i>pthread_cond_wait</i>()</a> with <i>m</i>
as the <i>mutex</i> argument (except as explicitly indicated otherwise for certain errors).</p>
</li>

<li>
<p>It returns (successfully or not) from <a href="../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a>
with <i>m</i> as the <i>mutex</i> argument (except as explicitly indicated otherwise for certain errors).</p>
</li>
</ul>

<p>The thread shall remain the owner of <i>m</i> until one of the following occurs:</p>

<ul>
<li>
<p>It executes <a href="../functions/pthread_mutex_unlock.html"><i>pthread_mutex_unlock</i>()</a> with <i>m</i> as the <i>mutex</i>
argument</p>
</li>

<li>
<p>It blocks in a call to <a href="../functions/pthread_cond_wait.html"><i>pthread_cond_wait</i>()</a> with <i>m</i> as the
<i>mutex</i> argument.</p>
</li>

<li>
<p>It blocks in a call to <a href="../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a> with <i>m</i> as
the <i>mutex</i> argument.</p>
</li>
</ul>

<p>The implementation shall behave as if at all times there is at most one owner of any mutex.</p>

<p>A thread that becomes the owner of a mutex is said to have ``acquired'' the mutex and the mutex is said to have become
``locked''; when a thread gives up ownership of a mutex it is said to have ``released'' the mutex and the mutex is said to have
become ``unlocked''.</p>

<h4><a name="tag_02_09_04"></a>Thread Scheduling</h4>

<p><sup>[<a href="javascript:open_code('TPS')">TPS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
The functionality described in this section is dependent on support of the Thread Execution Scheduling option (and the rest of this
section is not further marked for this option). <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>

<h5><a name="tag_02_09_04_01"></a>Thread Scheduling Attributes</h5>

<p>In support of the scheduling function, threads have attributes which are accessed through the <b>pthread_attr_t</b> thread
creation attributes object.</p>

<p>The <i>contentionscope</i> attribute defines the scheduling contention scope of the thread to be either PTHREAD_SCOPE_PROCESS or
PTHREAD_SCOPE_SYSTEM.</p>

<p>The <i>inheritsched</i> attribute specifies whether a newly created thread is to inherit the scheduling attributes of the
creating thread or to have its scheduling values set according to the other scheduling attributes in the <b>pthread_attr_t</b>
object.</p>

<p>The <i>schedpolicy</i> attribute defines the scheduling policy for the thread. The <i>schedparam</i> attribute defines the
scheduling parameters for the thread. The interaction of threads having different policies within a process is described as part of
the definition of those policies.</p>

<p>If the Thread Execution Scheduling option is defined, and the <i>schedpolicy</i> attribute specifies one of the priority-based
policies defined under this option, the <i>schedparam</i> attribute contains the scheduling priority of the thread. A conforming
implementation ensures that the priority value in <i>schedparam</i> is in the range associated with the scheduling policy when the
thread attributes object is used to create a thread, or when the scheduling attributes of a thread are dynamically modified. The
meaning of the priority value in <i>schedparam</i> is the same as that of <i>priority</i>.</p>

<p><sup>[<a href="javascript:open_code('TSP')">TSP</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
If _POSIX_THREAD_SPORADIC_SERVER is defined, the <i>schedparam</i> attribute supports four new members that are used for the
sporadic server scheduling policy. These members are <i>sched_ss_low_priority</i>, <i>sched_ss_repl_period</i>,
<i>sched_ss_init_budget</i>, and <i>sched_ss_max_repl</i>. The meaning of these attributes is the same as in the definitions that
appear under <a href="xsh_chap02_08.html#tag_02_08_04"><i>Process Scheduling</i></a> . <img src="../images/opt-end.gif" alt=
"[Option End]" border="0"></p>

<p>When a process is created, its single thread has a scheduling policy and associated attributes equal to the process' policy and
attributes. The default scheduling contention scope value is implementation-defined. The default values of other scheduling
attributes are implementation-defined.</p>

<h5><a name="tag_02_09_04_02"></a>Thread Scheduling Contention Scope</h5>

<p>The scheduling contention scope of a thread defines the set of threads with which the thread competes for use of the processing
resources. The scheduling operation selects at most one thread to execute on each processor at any point in time and the thread's
scheduling attributes (for example, <i>priority</i>), whether under process scheduling contention scope or system scheduling
contention scope, are the parameters used to determine the scheduling decision.</p>

<p>The scheduling contention scope, in the context of scheduling a mixed scope environment, affects threads as follows:</p>

<ul>
<li>
<p>A thread created with PTHREAD_SCOPE_SYSTEM scheduling contention scope contends for resources with all other threads in the same
scheduling allocation domain relative to their system scheduling attributes. The system scheduling attributes of a thread created
with PTHREAD_SCOPE_SYSTEM scheduling contention scope are the scheduling attributes with which the thread was created. The system
scheduling attributes of a thread created with PTHREAD_SCOPE_PROCESS scheduling contention scope are the implementation-defined
mapping into system attribute space of the scheduling attributes with which the thread was created.</p>
</li>

<li>
<p>Threads created with PTHREAD_SCOPE_PROCESS scheduling contention scope contend directly with other threads within their process
that were created with PTHREAD_SCOPE_PROCESS scheduling contention scope. The contention is resolved based on the threads'
scheduling attributes and policies. It is unspecified how such threads are scheduled relative to threads in other processes or
threads with PTHREAD_SCOPE_SYSTEM scheduling contention scope.</p>
</li>

<li>
<p>Conforming implementations shall support the PTHREAD_SCOPE_PROCESS scheduling contention scope, the PTHREAD_SCOPE_SYSTEM
scheduling contention scope, or both.</p>
</li>
</ul>

<h5><a name="tag_02_09_04_03"></a>Scheduling Allocation Domain</h5>

<p>Implementations shall support scheduling allocation domains containing one or more processors. It should be noted that the
presence of multiple processors does not automatically indicate a scheduling allocation domain size greater than one. Conforming
implementations on multi-processors may map all or any subset of the CPUs to one or multiple scheduling allocation domains, and
could define these scheduling allocation domains on a per-thread, per-process, or per-system basis, depending on the types of
applications intended to be supported by the implementation. The scheduling allocation domain is independent of scheduling
contention scope, as the scheduling contention scope merely defines the set of threads with which a thread contends for processor
resources, while scheduling allocation domain defines the set of processors for which it contends. The semantics of how this
contention is resolved among threads for processors is determined by the scheduling policies of the threads.</p>

<p>The choice of scheduling allocation domain size and the level of application control over scheduling allocation domains is
implementation-defined. Conforming implementations may change the size of scheduling allocation domains and the binding of threads
to scheduling allocation domains at any time.</p>

<p>For application threads with scheduling allocation domains of size equal to one, the scheduling rules defined for SCHED_FIFO and
SCHED_RR shall be used; see <a href="xsh_chap02_08.html#tag_02_08_04_01"><i>Scheduling Policies</i></a> . All threads with system
scheduling contention scope, regardless of the processes in which they reside, compete for the processor according to their
priorities. Threads with process scheduling contention scope compete only with other threads with process scheduling contention
scope within their process.</p>

<p>For application threads with scheduling allocation domains of size greater than one, the rules defined for SCHED_FIFO, SCHED_RR,
<sup>[<a href="javascript:open_code('TSP')">TSP</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
&nbsp;and SCHED_SPORADIC <img src="../images/opt-end.gif" alt="[Option End]" border="0"> shall be used in an implementation-defined
manner. Each thread with system scheduling contention scope competes for the processors in its scheduling allocation domain in an
implementation-defined manner according to its priority. Threads with process scheduling contention scope are scheduled relative to
other threads within the same scheduling contention scope in the process.</p>

<p><sup>[<a href="javascript:open_code('TSP')">TSP</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
If _POSIX_THREAD_SPORADIC_SERVER is defined, the rules defined for SCHED_SPORADIC in <a href=
"xsh_chap02_08.html#tag_02_08_04_01"><i>Scheduling Policies</i></a> shall be used in an implementation-defined manner for
application threads whose scheduling allocation domain size is greater than one. <img src="../images/opt-end.gif" alt=
"[Option End]" border="0"></p>

<h5><a name="tag_02_09_04_04"></a>Scheduling Documentation</h5>

<p>If _POSIX_PRIORITY_SCHEDULING is defined, then any scheduling policies beyond SCHED_OTHER, SCHED_FIFO, SCHED_RR, <sup>[<a href=
"javascript:open_code('TSP')">TSP</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;and
SCHED_SPORADIC, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> as well as the effects of the scheduling policies
indicated by these other values, and the attributes required in order to support such a policy, are implementation-defined.
Furthermore, the implementation shall document the effect of all processor scheduling allocation domain values supported for these
policies.</p>

<h4><a name="tag_02_09_05"></a>Thread Cancellation</h4>

<p>The thread cancellation mechanism allows a thread to terminate the execution of any other thread in the process in a controlled
manner. The target thread (that is, the one that is being canceled) is allowed to hold cancellation requests pending in a number of
ways and to perform application-specific cleanup processing when the notice of cancellation is acted upon.</p>

<p>Cancellation is controlled by the cancellation control functions. Each thread maintains its own cancelability state.
Cancellation may only occur at cancellation points or when the thread is asynchronously cancelable.</p>

<p>The thread cancellation mechanism described in this section depends upon programs having set <i>deferred</i> cancelability
state, which is specified as the default. Applications shall also carefully follow static lexical scoping rules in their execution
behavior. For example, use of <a href="../functions/setjmp.html"><i>setjmp</i>()</a>, <i>return</i>, <i>goto</i>, and so on, to
leave user-defined cancellation scopes without doing the necessary scope pop operation results in undefined behavior.</p>

<p>Use of asynchronous cancelability while holding resources which potentially need to be released may result in resource loss.
Similarly, cancellation scopes may only be safely manipulated (pushed and popped) when the thread is in the <i>deferred</i> or
<i>disabled</i> cancelability states.</p>

<h5><a name="tag_02_09_05_01"></a>Cancelability States</h5>

<p>The cancelability state of a thread determines the action taken upon receipt of a cancellation request. The thread may control
cancellation in a number of ways.</p>

<p>Each thread maintains its own cancelability state, which may be encoded in two bits:</p>

<ol>
<li>
<p>Cancelability-Enable: When cancelability is PTHREAD_CANCEL_DISABLE (as defined in the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/pthread.h.html"><i>&lt;pthread.h&gt;</i></a>), cancellation requests against
the target thread are held pending. By default, cancelability is set to PTHREAD_CANCEL_ENABLE (as defined in <a href=
"../basedefs/pthread.h.html"><i>&lt;pthread.h&gt;</i></a>).</p>
</li>

<li>
<p>Cancelability Type: When cancelability is enabled and the cancelability type is PTHREAD_CANCEL_ASYNCHRONOUS (as defined in <a
href="../basedefs/pthread.h.html"><i>&lt;pthread.h&gt;</i></a>), new or pending cancellation requests may be acted upon at any
time. When cancelability is enabled and the cancelability type is PTHREAD_CANCEL_DEFERRED (as defined in <a href=
"../basedefs/pthread.h.html"><i>&lt;pthread.h&gt;</i></a>), cancellation requests are held pending until a cancellation point (see
below) is reached. If cancelability is disabled, the setting of the cancelability type has no immediate effect as all cancellation