threads.html

unix 下的C开发手册,还用详细的例程。

A hybrid model offers the speed of library threads and the concurrency
of kernel threads.
In hybrid models, a process has some (relatively small) number of
kernel scheduled entities associated with it.
It also has a potentially much larger number of library threads
associated with it.
Some library threads may be bound to kernel scheduled entities, while
the other library threads are multiplexed onto the remaining kernel
scheduled entities.
There are two levels of thread scheduling:
<ul>
<p>
<li>
The run-time library manages the scheduling of (unbound) library threads
onto kernel scheduled entities.
<p>
<li>
The kernel manages the scheduling of kernel scheduled entities
onto processors.
<p>
</ul>
<p>
For this reason, a hybrid model is referred to as a &quot;two-level
threads scheduling model&quot;.
In this model, the process can have multiple concurrently executing
threads; specifically, it can have as many concurrently executing
threads as it has kernel scheduled entities.
<h4><a name = "tag_000_010_004">&nbsp;</a>Thread Mutexes</h4>
<p>
A thread that has blocked will not prevent any unblocked thread
that is eligible to use the same processing resources from
eventually making forward progress in its execution.
Eligibility for processing resources is
determined by the scheduling policy.
<p>
A thread becomes the owner of a mutex,
<i>m</i>,
when either:
<ol>
<p>
<li>
it returns successfully from
<i><a href="pthread_mutex_lock.html">pthread_mutex_lock()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument, or
<p>
<li>
it returns successfully from
<i><a href="pthread_mutex_trylock.html">pthread_mutex_trylock()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument, or
<p>
<li>
it returns (successfully or not) from
<i><a href="pthread_cond_wait.html">pthread_cond_wait()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument (except as explicitly indicated otherwise for certain
errors), or
<p>
<li>
it returns (successfully or not) from
<i><a href="pthread_cond_timedwait.html">pthread_cond_timedwait()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument (except as explicitly indicated otherwise for certain
errors).
<p>
</ol>
<p>
The thread remains the owner of
<i>m</i>
until it either:
<ol>
<p>
<li>
executes
<i><a href="pthread_mutex_unlock.html">pthread_mutex_unlock()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument, or
<p>
<li>
blocks in a call to
<i><a href="pthread_cond_wait.html">pthread_cond_wait()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument, or
<p>
<li>
blocks in a call to
<i><a href="pthread_cond_timedwait.html">pthread_cond_timedwait()</a></i>
with
<i>m</i>
as the
<i>mutex</i>
argument.
<p>
</ol>
<p>
The implementation behaves as if
at all times there is at most one
owner of any mutex.
<p>
A thread that becomes the
owner of a mutex is said to have
<i>acquired</i>
the mutex and the mutex is said to have become
<i>locked</i>;
when a thread gives up ownership
of a mutex it is said to have
<i>released</i>
the mutex and the mutex is said to have become
<i>unlocked</i>.
<h4><a name = "tag_000_010_005">&nbsp;</a>Thread Scheduling Attributes</h4>
<p>
In support of the scheduling interface, threads have attributes
which are accessed through the
<i>pthread_attr_t</i>
thread creation attributes object.
<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>
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
<i>pthread_attr_t</i>
object.
<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>
If the
_POSIX_THREAD_PRIORITY_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>
When a process is created,
its single thread has a scheduling policy and associated attributes
equal to the process's policy and attributes.
The default
scheduling contention scope
value is
implementation-dependent.
The default values of other scheduling attributes are
implementation-dependent.
<h4><a name = "tag_000_010_006">&nbsp;</a>Thread Scheduling Contention Scope</h4>
<p>
The scheduling contention scope
of a thread defines the set of threads with which
the thread must compete for use of the processing resources.
The scheduling operation will select at most one thread to execute
on each processor at any point in time
and the thread's scheduling attributes (for example, priority),
whether under process scheduling contention scope
or system scheduling contention scope,
are the parameters used to determine the scheduling decision.
<p>
The scheduling contention scope,
in the context of scheduling a mixed scope environment,
effects threads as follows:
<ul>
<p>
<li>
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-dependent mapping into system attribute space
of the scheduling attributes with which the thread was created.
<p>
<li>
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>
Conforming implementations support
the PTHREAD_SCOPE_PROCESS scheduling contention scope,
the PTHREAD_SCOPE_SYSTEM scheduling contention scope, or both.
<p>
</ul>
<h4><a name = "tag_000_010_007">&nbsp;</a>Scheduling Allocation Domain</h4>
<p>
Implementations 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 must contend
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>
The choice of scheduling allocation domain
size and the level of application control over
scheduling allocation domains is implementation-dependent.
Conforming implementations may change the size of
scheduling allocation domains and the binding of threads to
scheduling allocation domains at any time.
<p>
For application threads with scheduling allocation domains
of size equal to one, the scheduling rules defined for
SCHED_FIFO and SCHED_RR will be used.
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>
For application threads with scheduling allocation domains
of size greater than one, the rules defined for SCHED_FIFO
and SCHED_RR are used in an implementation-dependent manner.
Each thread with system scheduling contention scope
competes for the processors in its scheduling allocation domain
in an implementation-dependent 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.
<h4><a name = "tag_000_010_008">&nbsp;</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>
Cancellation is controlled by the cancellation control interfaces.
Each thread maintains its own cancelability state.
Cancellation may only occur at cancellation points
or when the thread is asynchronously cancelable.
<p>
The thread cancellation mechanism described in this section
depends upon programs having set
<i>deferred cancelability</i>
state, which is specified as the default.
Applications must also carefully follow static lexical scoping rules
in their execution behaviour.
For instance, use of
<i><a href="setjmp.html">setjmp()</a></i>,
return, goto, and so on, to leave user-defined cancellation
scopes without doing the necessary scope pop operation
will result in undefined behaviour.
<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>