xsh_chap02_08.html

IEEE 1003.1-2003, Single Unix Specification v3

maps a file, its contents are shared among them. If the mappings allow shared write access, then data written into the memory
object through the address space of one process appears in the address spaces of all processes that similarly map the same portion
of the memory object.</p>

<p><sup>[<a href="javascript:open_code('SHM')">SHM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
Shared memory objects are named regions of storage that may be independent of the file system and can be mapped into the address
space of one or more processes to allow them to share the associated memory. <img src="../images/opt-end.gif" alt="[Option End]"
border="0"></p>

<p>An <a href="../functions/unlink.html"><i>unlink</i>()</a> of a file <sup>[<a href="javascript:open_code('SHM')">SHM</a>]</sup>
<img src="../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;or <a href=
"../functions/shm_unlink.html"><i>shm_unlink</i>()</a> of a shared memory object, <img src="../images/opt-end.gif" alt=
"[Option End]" border="0"> while causing the removal of the name, does not unmap any mappings established for the object. Once the
name has been removed, the contents of the memory object are preserved as long as it is referenced. The memory object remains
referenced as long as a process has the memory object open or has some area of the memory object mapped.</p>

<h5><a name="tag_02_08_03_03"></a>Memory Protection</h5>

<p><sup>[<a href="javascript:open_code('MPR MF')">MPR MF</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 Memory Protection and Memory Mapped Files option
(and the rest of this section is not further marked for these options). <img src="../images/opt-end.gif" alt="[Option End]" border=
"0"></p>

<p>When an object is mapped, various application accesses to the mapped region may result in signals. In this context, SIGBUS is
used to indicate an error using the mapped object, and SIGSEGV is used to indicate a protection violation or misuse of an
address:</p>

<ul>
<li>
<p>A mapping may be restricted to disallow some types of access.</p>
</li>

<li>
<p>Write attempts to memory that was mapped without write access, or any access to memory mapped PROT_NONE, shall result in a
SIGSEGV signal.</p>
</li>

<li>
<p>References to unmapped addresses shall result in a SIGSEGV signal.</p>
</li>

<li>
<p>Reference to whole pages within the mapping, but beyond the current length of the object, shall result in a SIGBUS signal.</p>
</li>

<li>
<p>The size of the object is unaffected by access beyond the end of the object (even if a SIGBUS is not generated).</p>
</li>
</ul>

<h5><a name="tag_02_08_03_04"></a>Typed Memory Objects</h5>

<p><sup>[<a href="javascript:open_code('TYM')">TYM</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 Typed Memory Objects 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>

<p>Implementations may support the Typed Memory Objects option without supporting the Memory Mapped Files option or the Shared
Memory Objects option. Typed memory objects are implementation-configurable named storage pools accessible from one or more
processors in a system, each via one or more ports, such as backplane buses, LANs, I/O channels, and so on. Each valid combination
of a storage pool and a port is identified through a name that is defined at system configuration time, in an
implementation-defined manner; the name may be independent of the file system. Using this name, a typed memory object can be opened
and mapped into process address space. For a given storage pool and port, it is necessary to support both dynamic allocation from
the pool as well as mapping at an application-supplied offset within the pool; when dynamic allocation has been performed,
subsequent deallocation must be supported. Lastly, accessing typed memory objects from different ports requires a method for
obtaining the offset and length of contiguous storage of a region of typed memory (dynamically allocated or not); this allows typed
memory to be shared among processes and/or processors while being accessed from the desired port.</p>

<h4><a name="tag_02_08_04"></a>Process Scheduling</h4>

<p><sup>[<a href="javascript:open_code('PS')">PS</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 Process 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_08_04_01"></a>Scheduling Policies</h5>

<p>The scheduling semantics described in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 are defined in terms of a conceptual model
that contains a set of thread lists. No implementation structures are necessarily implied by the use of this conceptual model. It
is assumed that no time elapses during operations described using this model, and therefore no simultaneous operations are
possible. This model discusses only processor scheduling for runnable threads, but it should be noted that greatly enhanced
predictability of realtime applications results if the sequencing of other resources takes processor scheduling policy into
account.</p>

<p>There is, conceptually, one thread list for each priority. A runnable thread will be on the thread list for that thread's
priority. Multiple scheduling policies shall be provided. Each non-empty thread list is ordered, contains a head as one end of its
order, and a tail as the other. The purpose of a scheduling policy is to define the allowable operations on this set of lists (for
example, moving threads between and within lists).</p>

<p>Each process shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit
application execution of the <a href="../functions/sched_setscheduler.html"><i>sched_setscheduler</i>()</a> or <a href=
"../functions/sched_setparam.html"><i>sched_setparam</i>()</a> functions.</p>

<p>Each thread shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit
application execution of the <a href="../functions/pthread_setschedparam.html"><i>pthread_setschedparam</i>()</a> function.</p>

<p>Associated with each policy is a priority range. Each policy definition shall specify the minimum priority range for that
policy. The priority ranges for each policy may but need not overlap the priority ranges of other policies.</p>

<p>A conforming implementation shall select the thread that is defined as being at the head of the highest priority non-empty
thread list to become a running thread, regardless of its associated policy. This thread is then removed from its thread list.</p>

<p>Four scheduling policies are specifically required. Other implementation-defined scheduling policies may be defined. The
following symbols are defined in the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/sched.h.html"><i>&lt;sched.h&gt;</i></a>:</p>

<dl compact>
<dt>SCHED_FIFO</dt>

<dd>First in, first out (FIFO) scheduling policy.</dd>

<dt>SCHED_RR</dt>

<dd>Round robin scheduling policy.</dd>

<dt>SCHED_SPORADIC</dt>

<dd><sup>[<a href="javascript:open_code('SS')">SS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
Sporadic server scheduling policy. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></dd>

<dt>SCHED_OTHER</dt>

<dd>Another scheduling policy.</dd>
</dl>

<p>The values of these symbols shall be distinct.</p>

<h5><a name="tag_02_08_04_02"></a>SCHED_FIFO</h5>

<p>Conforming implementations shall include a scheduling policy called the FIFO scheduling policy.</p>

<p>Threads scheduled under this policy are chosen from a thread list that is ordered by the time its threads have been on the list
without being executed; generally, the head of the list is the thread that has been on the list the longest time, and the tail is
the thread that has been on the list the shortest time.</p>

<p>Under the SCHED_FIFO policy, the modification of the definitional thread lists is as follows:</p>

<ol>
<li>
<p>When a running thread becomes a preempted thread, it becomes the head of the thread list for its priority.</p>
</li>

<li>
<p>When a blocked thread becomes a runnable thread, it becomes the tail of the thread list for its priority.</p>
</li>

<li>
<p>When a running thread calls the <a href="../functions/sched_setscheduler.html"><i>sched_setscheduler</i>()</a> function, the
process specified in the function call is modified to the specified policy and the priority specified by the <i>param</i>
argument.</p>
</li>

<li>
<p>When a running thread calls the <a href="../functions/sched_setparam.html"><i>sched_setparam</i>()</a> function, the priority of
the process specified in the function call is modified to the priority specified by the <i>param</i> argument.</p>
</li>

<li>
<p>When a running thread calls the <a href="../functions/pthread_setschedparam.html"><i>pthread_setschedparam</i>()</a> function,
the thread specified in the function call is modified to the specified policy and the priority specified by the <i>param</i>
argument.</p>
</li>

<li>
<p>When a running thread calls the <a href="../functions/pthread_setschedprio.html"><i>pthread_setschedprio</i>()</a> function, the
thread specified in the function call is modified to the priority specified by the <i>prio</i> argument.</p>
</li>

<li>
<p>If a thread whose policy or priority has been modified other than by <a href=
"../functions/pthread_setschedprio.html"><i>pthread_setschedprio</i>()</a> is a running thread or is runnable, it then becomes the
tail of the thread list for its new priority.</p>
</li>

<li>
<p>If a thread whose policy or priority has been modified by <a href=
"../functions/pthread_setschedprio.html"><i>pthread_setschedprio</i>()</a> is a running thread or is runnable, the effect on its
position in the thread list depends on the direction of the modification, as follows:</p>

<ol type="a">
<li>
<p>If the priority is raised, the thread becomes the tail of the thread list.</p>
</li>

<li>
<p>If the priority is unchanged, the thread does not change position in the thread list.</p>
</li>

<li>
<p>If the priority is lowered, the thread becomes the head of the thread list.</p>
</li>
</ol>
</li>

<li>
<p>When a running thread issues the <a href="../functions/sched_yield.html"><i>sched_yield</i>()</a> function, the thread becomes
the tail of the thread list for its priority.</p>
</li>

<li>
<p>At no other time is the position of a thread with this scheduling policy within the thread lists affected.</p>
</li>
</ol>

<p>For this policy, valid priorities shall be within the range returned by the <a href=
"../functions/sched_get_priority_max.html"><i>sched_get_priority_max</i>()</a> and <a href=
"../functions/sched_get_priority_min.html"><i>sched_get_priority_min</i>()</a> functions when SCHED_FIFO is provided as the
parameter. Conforming implementations shall provide a priority range of at least 32 priorities for this policy.</p>

<h5><a name="tag_02_08_04_03"></a>SCHED_RR</h5>

<p>Conforming implementations shall include a scheduling policy called the ``round robin'' scheduling policy. This policy shall be
identical to the SCHED_FIFO policy with the additional condition that when the implementation detects that a running thread has
been executing as a running thread for a time period of the length returned by the <a href=
"../functions/sched_rr_get_interval.html"><i>sched_rr_get_interval</i>()</a> function or longer, the thread shall become the tail
of its thread list and the head of that thread list shall be removed and made a running thread.</p>

<p>The effect of this policy is to ensure that if there are multiple SCHED_RR threads at the same priority, one of them does not
monopolize the processor. An application should not rely only on the use of SCHED_RR to ensure application progress among multiple
threads if the application includes threads using the SCHED_FIFO policy at the same or higher priority levels or SCHED_RR threads
at a higher priority level.</p>

<p>A thread under this policy that is preempted and subsequently resumes execution as a running thread completes the unexpired
portion of its round robin interval time period.</p>

<p>For this policy, valid priorities shall be within the range returned by the <a href=
"../functions/sched_get_priority_max.html"><i>sched_get_priority_max</i>()</a> and <a href=
"../functions/sched_get_priority_min.html"><i>sched_get_priority_min</i>()</a> functions when SCHED_RR is provided as the
parameter. Conforming implementations shall provide a priority range of at least 32 priorities for this policy.</p>

<h5><a name="tag_02_08_04_04"></a>SCHED_SPORADIC</h5>

<p><sup>[<a href="javascript:open_code('SS')">SS|TSP</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 Process Sporadic Server or Thread Sporadic Server
options (and the rest of this section is not further marked for these options). <img src="../images/opt-end.gif" alt="[Option End]"
border="0"></p>

<p>If _POSIX_SPORADIC_SERVER or _POSIX_THREAD_SPORADIC_SERVER is defined, the implementation shall include a scheduling policy
identified by the value SCHED_SPORADIC.</p>

<p>The sporadic server policy is based primarily on two parameters: the replenishment period and the available execution capacity.
The replenishment period is given by the <i>sched_ss_repl_period</i> member of the <b>sched_param</b> structure. The available
execution capacity is initialized to the value given by the <i>sched_ss_init_budget</i> member of the same parameter. The sporadic
server policy is identical to the SCHED_FIFO policy with some additional conditions that cause the thread's assigned priority to be
switched between the values specified by the <i>sched_priority</i> and <i>sched_ss_low_priority</i> members of the
<b>sched_param</b> structure.</p>

<p>The priority assigned to a thread using the sporadic server scheduling policy is determined in the following manner: if the
available execution capacity is greater than zero and the number of pending replenishment operations is strictly less than
<i>sched_ss_max_repl</i>, the thread is assigned the priority specified by <i>sched_priority</i>; otherwise, the assigned priority
shall be <i>sched_ss_low_priority</i>. If the value of <i>sched_priority</i> is less than or equal to the value of
<i>sched_ss_low_priority</i>, the results are undefined. When active, the thread shall belong to the thread list corresponding to
its assigned priority level, according to the mentioned priority assignment. The modification of the available execution capacity
and, consequently of the assigned priority, is done as follows:</p>

<ol>
<li>
<p>When the thread at the head of the <i>sched_priority</i> list becomes a running thread, its execution time shall be limited to
at most its available execution capacity, plus the resolution of the execution time clock used for this scheduling policy. This
resolution shall be implementation-defined.</p>
</li>

<li>
<p>Each time the thread is inserted at the tail of the list associated with <i>sched_priority</i>- because as a blocked thread it
became runnable with priority <i>sched_priority</i> or because a replenishment operation was performed-the time at which this
operation is done is posted as the <i>activation_time</i>.</p>
</li>

<li>
<p>When the running thread with assigned priority equal to <i>sched_priority</i> becomes a preempted thread, it becomes the head of
the thread list for its priority, and the execution time consumed is subtracted from the available execution capacity. If the
available execution capacity would become negative by this operation, it shall be set to zero.</p>
</li>