810 lines
42 KiB
HTML
810 lines
42 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>System Interfaces Chapter 2</title>
|
|
</head>
|
|
<body>
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3">
|
|
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001</font></center>
|
|
|
|
<hr size="2" noshade>
|
|
<h3><a name="tag_02_08"></a>Realtime</h3>
|
|
|
|
<p>This section defines functions to support the source portability of applications with realtime requirements. The presence of
|
|
many of these functions is dependent on support for implementation options described in the text.</p>
|
|
|
|
<p>The specific functional areas included in this section and their scope include the following. Full definitions of these terms
|
|
can be found in the Base Definitions volume of IEEE Std 1003.1-2001, <a href="../basedefs/xbd_chap03.html">Chapter 3,
|
|
Definitions</a>.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>Semaphores</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Process Memory Locking</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Memory Mapped Files and Shared Memory Objects</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Priority Scheduling</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Realtime Signal Extension</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Timers</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Interprocess Communication</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Synchronized Input and Output</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Asynchronous Input and Output</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>All the realtime functions defined in this volume of IEEE Std 1003.1-2001 are portable, although some of the numeric
|
|
parameters used by an implementation may have hardware dependencies.</p>
|
|
|
|
<h4><a name="tag_02_08_01"></a>Realtime Signals</h4>
|
|
|
|
<p><sup>[<a href="javascript:open_code('RTS')">RTS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Realtime signal generation and delivery is dependent on support for the Realtime Signals Extension option. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p>See <a href="xsh_chap02_04.html#tag_02_04_02"><i>Realtime Signal Generation and Delivery</i></a> .</p>
|
|
|
|
<h4><a name="tag_02_08_02"></a>Asynchronous I/O</h4>
|
|
|
|
<p><sup>[<a href="javascript:open_code('AIO')">AIO</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 Asynchronous Input and Output 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>An asynchronous I/O control block structure <b>aiocb</b> is used in many asynchronous I/O functions. It is defined in the Base
|
|
Definitions volume of IEEE Std 1003.1-2001, <a href="../basedefs/aio.h.html"><i><aio.h></i></a> and has at least
|
|
the following members:</p>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="3" align="center">
|
|
<tr valign="top">
|
|
<th align="center">
|
|
<p class="tent"><b>Member Type</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Member Name</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Description</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>int</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_fildes</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">File descriptor.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>off_t</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_offset</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">File offset.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>volatile void*</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_buf</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Location of buffer.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>size_t</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_nbytes</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Length of transfer.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>int</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_reqprio</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Request priority offset.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>struct sigevent</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_sigevent</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Signal number and value.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>int</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>aio_lio_opcode</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Operation to be performed.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
|
|
<p>The <i>aio_fildes</i> element is the file descriptor on which the asynchronous operation is performed.</p>
|
|
|
|
<p>If O_APPEND is not set for the file descriptor <i>aio_fildes</i> and if <i>aio_fildes</i> is associated with a device that is
|
|
capable of seeking, then the requested operation takes place at the absolute position in the file as given by <i>aio_offset</i>, as
|
|
if <a href="../functions/lseek.html"><i>lseek</i>()</a> were called immediately prior to the operation with an <i>offset</i>
|
|
argument equal to <i>aio_offset</i> and a <i>whence</i> argument equal to SEEK_SET. If O_APPEND is set for the file descriptor, or
|
|
if <i>aio_fildes</i> is associated with a device that is incapable of seeking, write operations append to the file in the same
|
|
order as the calls were made, with the following exception: under implementation-defined circumstances, such as operation on a
|
|
multi-processor or when requests of differing priorities are submitted at the same time, the ordering restriction may be relaxed.
|
|
Since there is no way for a strictly conforming application to determine whether this relaxation applies, all strictly conforming
|
|
applications which rely on ordering of output shall be written in such a way that they will operate correctly if the relaxation
|
|
applies. After a successful call to enqueue an asynchronous I/O operation, the value of the file offset for the file is
|
|
unspecified. The <i>aio_nbytes</i> and <i>aio_buf</i> elements are the same as the <i>nbyte</i> and <i>buf</i> arguments defined by
|
|
<a href="../functions/read.html"><i>read</i>()</a> and <a href="../functions/write.html"><i>write</i>()</a>, respectively.</p>
|
|
|
|
<p>If _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are defined, then asynchronous I/O is queued in priority order, with the
|
|
priority of each asynchronous operation based on the current scheduling priority of the calling process. The <i>aio_reqprio</i>
|
|
member can be used to lower (but not raise) the asynchronous I/O operation priority and is within the range zero through
|
|
{AIO_PRIO_DELTA_MAX}, inclusive. Unless both _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are defined, the order of
|
|
processing asynchronous I/O requests is unspecified. When both _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING are defined,
|
|
the order of processing of requests submitted by processes whose schedulers are not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC is
|
|
unspecified. The priority of an asynchronous request is computed as (process scheduling priority) minus <i>aio_reqprio</i>. The
|
|
priority assigned to each asynchronous I/O request is an indication of the desired order of execution of the request relative to
|
|
other asynchronous I/O requests for this file. If _POSIX_PRIORITIZED_IO is defined, requests issued with the same priority to a
|
|
character special file are processed by the underlying device in FIFO order; the order of processing of requests of the same
|
|
priority issued to files that are not character special files is unspecified. Numerically higher priority values indicate requests
|
|
of higher priority. The value of <i>aio_reqprio</i> has no effect on process scheduling priority. When prioritized asynchronous I/O
|
|
requests to the same file are blocked waiting for a resource required for that I/O operation, the higher-priority I/O requests
|
|
shall be granted the resource before lower-priority I/O requests are granted the resource. The relative priority of asynchronous
|
|
I/O and synchronous I/O is implementation-defined. If _POSIX_PRIORITIZED_IO is defined, the implementation shall define for which
|
|
files I/O prioritization is supported.</p>
|
|
|
|
<p>The <i>aio_sigevent</i> determines how the calling process shall be notified upon I/O completion, as specified in <a href=
|
|
"xsh_chap02_04.html#tag_02_04_01"><i>Signal Generation and Delivery</i></a> . If <i>aio_sigevent.sigev_notify</i> is SIGEV_NONE,
|
|
then no signal shall be posted upon I/O completion, but the error status for the operation and the return status for the operation
|
|
shall be set appropriately.</p>
|
|
|
|
<p>The <i>aio_lio_opcode</i> field is used only by the <a href="../functions/lio_listio.html"><i>lio_listio</i>()</a> call. The <a
|
|
href="../functions/lio_listio.html"><i>lio_listio</i>()</a> call allows multiple asynchronous I/O operations to be submitted at a
|
|
single time. The function takes as an argument an array of pointers to <b>aiocb</b> structures. Each <b>aiocb</b> structure
|
|
indicates the operation to be performed (read or write) via the <i>aio_lio_opcode</i> field.</p>
|
|
|
|
<p>The address of the <b>aiocb</b> structure is used as a handle for retrieving the error status and return status of the
|
|
asynchronous operation while it is in progress.</p>
|
|
|
|
<p>The <b>aiocb</b> structure and the data buffers associated with the asynchronous I/O operation are being used by the system for
|
|
asynchronous I/O while, and only while, the error status of the asynchronous operation is equal to [EINPROGRESS]. Applications
|
|
shall not modify the <b>aiocb</b> structure while the structure is being used by the system for asynchronous I/O.</p>
|
|
|
|
<p>The return status of the asynchronous operation is the number of bytes transferred by the I/O operation. If the error status is
|
|
set to indicate an error completion, then the return status is set to the return value that the corresponding <a href=
|
|
"../functions/read.html"><i>read</i>()</a>, <a href="../functions/write.html"><i>write</i>()</a>, or <a href=
|
|
"../functions/fsync.html"><i>fsync</i>()</a> call would have returned. When the error status is not equal to [EINPROGRESS], the
|
|
return status shall reflect the return status of the corresponding synchronous operation.</p>
|
|
|
|
<h4><a name="tag_02_08_03"></a>Memory Management</h4>
|
|
|
|
<h5><a name="tag_02_08_03_01"></a>Memory Locking</h5>
|
|
|
|
<p><sup>[<a href="javascript:open_code('ML')">ML</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 Memory Locking 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>Range memory locking operations are defined in terms of pages. Implementations may restrict the size and alignment of range
|
|
lockings to be on page-size boundaries. The page size, in bytes, is the value of the configurable system variable {PAGESIZE}. If an
|
|
implementation has no restrictions on size or alignment, it may specify a 1-byte page size.</p>
|
|
|
|
<p>Memory locking guarantees the residence of portions of the address space. It is implementation-defined whether locking memory
|
|
guarantees fixed translation between virtual addresses (as seen by the process) and physical addresses. Per-process memory locks
|
|
are not inherited across a <a href="../functions/fork.html"><i>fork</i>()</a>, and all memory locks owned by a process are unlocked
|
|
upon <i><a href="../functions/exec.html">exec</a></i> or process termination. Unmapping of an address range removes any memory
|
|
locks established on that address range by this process.</p>
|
|
|
|
<h5><a name="tag_02_08_03_02"></a>Memory Mapped Files</h5>
|
|
|
|
<p><sup>[<a href="javascript:open_code('MF')">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 Mapped Files 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>Range memory mapping operations are defined in terms of pages. Implementations may restrict the size and alignment of range
|
|
mappings to be on page-size boundaries. The page size, in bytes, is the value of the configurable system variable {PAGESIZE}. If an
|
|
implementation has no restrictions on size or alignment, it may specify a 1-byte page size.</p>
|
|
|
|
<p>Memory mapped files provide a mechanism that allows a process to access files by directly incorporating file data into its
|
|
address space. Once a file is mapped into a process address space, the data can be manipulated as memory. If more than one process
|
|
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"> 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 Std 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 Std 1003.1-2001, <a href=
|
|
"../basedefs/sched.h.html"><i><sched.h></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>
|
|
|
|
<li>
|
|
<p>When the running thread with assigned priority equal to <i>sched_priority</i> becomes a blocked thread, the execution time
|
|
consumed is subtracted from the available execution capacity, and a replenishment operation is scheduled, as described in 6 and 7.
|
|
If the available execution capacity would become negative by this operation, it shall be set to zero.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>When the running thread with assigned priority equal to <i>sched_priority</i> reaches the limit imposed on its execution time,
|
|
it becomes the tail of the thread list for <i>sched_ss_low_priority</i>, the execution time consumed is subtracted from the
|
|
available execution capacity (which becomes zero), and a replenishment operation is scheduled, as described in 6 and 7.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Each time a replenishment operation is scheduled, the amount of execution capacity to be replenished, <i>replenish_amount</i>,
|
|
is set equal to the execution time consumed by the thread since the <i>activation_time</i>. The replenishment is scheduled to occur
|
|
at <i>activation_time</i> plus <i>sched_ss_repl_period</i>. If the scheduled time obtained is before the current time, the
|
|
replenishment operation is carried out immediately. Several replenishment operations may be pending at the same time, each of which
|
|
will be serviced at its respective scheduled time. With the above rules, the number of replenishment operations simultaneously
|
|
pending for a given thread that is scheduled under the sporadic server policy shall not be greater than
|
|
<i>sched_ss_max_repl</i>.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A replenishment operation consists of adding the corresponding <i>replenish_amount</i> to the available execution capacity at
|
|
the scheduled time. If, as a consequence of this operation, the execution capacity would become larger than
|
|
<i>sched_ss_initial_budget</i>, it shall be rounded down to a value equal to <i>sched_ss_initial_budget</i>. Additionally, if the
|
|
thread was runnable or running, and had assigned priority equal to <i>sched_ss_low_priority</i>, then it becomes the tail of the
|
|
thread list for <i>sched_priority</i>.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Execution time is defined in <a href="xsh_chap02_02.html#tag_02_02_02"><i>The Name Space</i></a> .</p>
|
|
|
|
<p>For this policy, changing the value of a CPU-time clock via <a href="../functions/clock_settime.html"><i>clock_settime</i>()</a>
|
|
shall have no effect on its behavior.</p>
|
|
|
|
<p>For this policy, valid priorities shall be within the range returned by the <a href=
|
|
"../functions/sched_get_priority_min.html"><i>sched_get_priority_min</i>()</a> and <a href=
|
|
"../functions/sched_get_priority_max.html"><i>sched_get_priority_max</i>()</a> functions when SCHED_SPORADIC is provided as the
|
|
parameter. Conforming implementations shall provide a priority range of at least 32 distinct priorities for this policy.</p>
|
|
|
|
<h5><a name="tag_02_08_04_05"></a>SCHED_OTHER</h5>
|
|
|
|
<p>Conforming implementations shall include one scheduling policy identified as SCHED_OTHER (which may execute identically with
|
|
either the FIFO or round robin scheduling policy). The effect of scheduling threads with the SCHED_OTHER policy in a system in
|
|
which other threads are executing under SCHED_FIFO, SCHED_RR, <sup>[<a href="javascript:open_code('SS')">SS</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> or SCHED_SPORADIC <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"> is implementation-defined.</p>
|
|
|
|
<p>This policy is defined to allow strictly conforming applications to be able to indicate in a portable manner that they no longer
|
|
need a realtime scheduling policy.</p>
|
|
|
|
<p>For threads executing under this policy, the implementation shall use only priorities 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_OTHER is provided as the
|
|
parameter.</p>
|
|
|
|
<h4><a name="tag_02_08_05"></a>Clocks and Timers</h4>
|
|
|
|
<p><sup>[<a href="javascript:open_code('TMR')">TMR</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 Timers option (and the rest of this section is not
|
|
further shaded for this option). <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p>The <a href="../basedefs/time.h.html"><i><time.h></i></a> header defines the types and manifest constants used by the
|
|
timing facility.</p>
|
|
|
|
<h5><a name="tag_02_08_05_01"></a>Time Value Specification Structures</h5>
|
|
|
|
<p>Many of the timing facility functions accept or return time value specifications. A time value structure <b>timespec</b>
|
|
specifies a single time value and includes at least the following members:</p>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="3" align="center">
|
|
<tr valign="top">
|
|
<th align="center">
|
|
<p class="tent"><b>Member Type</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Member Name</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Description</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>time_t</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>tv_sec</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Seconds.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>long</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>tv_nsec</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Nanoseconds.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
|
|
<p>The <i>tv_nsec</i> member is only valid if greater than or equal to zero, and less than the number of nanoseconds in a second
|
|
(1000 million). The time interval described by this structure is (<i>tv_sec</i> * 10<sup><small>9</small></sup> + <i>tv_nsec</i>)
|
|
nanoseconds.</p>
|
|
|
|
<p>A time value structure <b>itimerspec</b> specifies an initial timer value and a repetition interval for use by the per-process
|
|
timer functions. This structure includes at least the following members:</p>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="3" align="center">
|
|
<tr valign="top">
|
|
<th align="center">
|
|
<p class="tent"><b>Member Type</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Member Name</b></p>
|
|
</th>
|
|
<th align="center">
|
|
<p class="tent"><b>Description</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>struct timespec</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>it_interval</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Timer period.</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>struct timespec</b></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent"><i>it_value</i></p>
|
|
</td>
|
|
<td align="left">
|
|
<p class="tent">Timer expiration.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
|
|
<p>If the value described by <i>it_value</i> is non-zero, it indicates the time to or time of the next timer expiration (for
|
|
relative and absolute timer values, respectively). If the value described by <i>it_value</i> is zero, the timer shall be
|
|
disarmed.</p>
|
|
|
|
<p>If the value described by <i>it_interval</i> is non-zero, it specifies an interval which shall be used in reloading the timer
|
|
when it expires; that is, a periodic timer is specified. If the value described by <i>it_interval</i> is zero, the timer is
|
|
disarmed after its next expiration; that is, a one-shot timer is specified.</p>
|
|
|
|
<h5><a name="tag_02_08_05_02"></a>Timer Event Notification Control Block</h5>
|
|
|
|
<p><sup>[<a href="javascript:open_code('RTS')">RTS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Per-process timers may be created that notify the process of timer expirations by queuing a realtime extended signal. The
|
|
<b>sigevent</b> structure, defined in the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/signal.h.html"><i><signal.h></i></a>, is used in creating such a timer. The <b>sigevent</b> structure contains
|
|
the signal number and an application-specific data value which shall be used when notifying the calling process of timer expiration
|
|
events. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<h5><a name="tag_02_08_05_03"></a>Manifest Constants</h5>
|
|
|
|
<p>The following constants are defined in the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/time.h.html"><i><time.h></i></a>:</p>
|
|
|
|
<dl compact>
|
|
<dt>CLOCK_REALTIME</dt>
|
|
|
|
<dd>The identifier for the system-wide realtime clock.</dd>
|
|
|
|
<dt>TIMER_ABSTIME</dt>
|
|
|
|
<dd>Flag indicating time is absolute with respect to the clock associated with a timer.</dd>
|
|
|
|
<dt>CLOCK_MONOTONIC</dt>
|
|
|
|
<dd><sup>[<a href="javascript:open_code('MON')">MON</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The identifier for the system-wide monotonic clock, which is defined as a clock whose value cannot be set via <a href=
|
|
"../functions/clock_settime.html"><i>clock_settime</i>()</a> and which cannot have backward clock jumps. The maximum possible clock
|
|
jump is implementation-defined. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></dd>
|
|
</dl>
|
|
|
|
<p>The maximum allowable resolution for CLOCK_REALTIME and <sup>[<a href="javascript:open_code('MON')">MON</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> CLOCK_MONOTONIC <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"> clocks and all time services based on these clocks is represented by {_POSIX_CLOCKRES_MIN} and shall be
|
|
defined as 20 ms (1/50 of a second). Implementations may support smaller values of resolution for these clocks to provide finer
|
|
granularity time bases. The actual resolution supported by an implementation for a specific clock is obtained using the <a href=
|
|
"../functions/clock_getres.html"><i>clock_getres</i>()</a> function. If the actual resolution supported for a time service based on
|
|
one of these clocks differs from the resolution supported for that clock, the implementation shall document this difference.</p>
|
|
|
|
<p>The minimum allowable maximum value for CLOCK_REALTIME and <sup>[<a href="javascript:open_code('MON')">MON</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> CLOCK_MONOTONIC <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"> clocks and all absolute time services based on them is the same as that defined by the ISO C
|
|
standard for the <b>time_t</b> type. If the maximum value supported by a time service based on one of these clocks differs from the
|
|
maximum value supported by that clock, the implementation shall document this difference.</p>
|
|
|
|
<h5><a name="tag_02_08_05_04"></a>Execution Time Monitoring</h5>
|
|
|
|
<p><sup>[<a href="javascript:open_code('CPT')">CPT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If _POSIX_CPUTIME is defined, process CPU-time clocks shall be supported in addition to the clocks described in <a href=
|
|
"#tag_02_08_05_03">Manifest Constants</a> . <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('TCT')">TCT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If _POSIX_THREAD_CPUTIME is defined, thread CPU-time clocks shall be supported. <img src="../images/opt-end.gif" alt="[Option End]"
|
|
border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('CPT')">CPT|TCT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border=
|
|
"0"> CPU-time clocks measure execution or CPU time, which is defined in the Base Definitions volume of
|
|
IEEE Std 1003.1-2001, <a href="../basedefs/xbd_chap03.html#tag_03_117">Section 3.117, CPU Time (Execution Time)</a>. The
|
|
mechanism used to measure execution time is described in the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/xbd_chap04.html#tag_04_09">Section 4.9, Measurement of Execution Time</a>. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('CPT')">CPT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If _POSIX_CPUTIME is defined, the following constant of the type <b>clockid_t</b> is defined in <a href=
|
|
"../basedefs/time.h.html"><i><time.h></i></a>:</p>
|
|
|
|
<dl compact>
|
|
<dt>CLOCK_PROCESS_CPUTIME_ID</dt>
|
|
|
|
<dd><br>
|
|
When this value of the type <b>clockid_t</b> is used in a <a href="../functions/clock.html"><i>clock</i>()</a> or <a href=
|
|
"../functions/timer_create.html"><i>timer*</i>()</a> function call, it is interpreted as the identifier of the CPU-time clock associated
|
|
with the process making the function call.</dd>
|
|
</dl>
|
|
|
|
<img src="../images/opt-end.gif" alt="[Option End]" border="0">
|
|
|
|
<p><sup>[<a href="javascript:open_code('TCT')">TCT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If _POSIX_THREAD_CPUTIME is defined, the following constant of the type <b>clockid_t</b> is defined in <a href=
|
|
"../basedefs/time.h.html"><i><time.h></i></a>:</p>
|
|
|
|
<dl compact>
|
|
<dt>CLOCK_THREAD_CPUTIME_ID</dt>
|
|
|
|
<dd><br>
|
|
When this value of the type <b>clockid_t</b> is used in a <a href="../functions/clock.html"><i>clock</i>()</a> or <a href=
|
|
"../functions/timer_create.html"><i>timer*</i>()</a> function call, it is interpreted as the identifier of the CPU-time clock associated
|
|
with the thread making the function call. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></dd>
|
|
</dl>
|
|
|
|
<hr size="2" noshade>
|
|
<center><font size="2">UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
</font> [ <a href="../mindex.html">Main Index</a>]</center>
|
|
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|