realtime.html

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

structure is used as a
handle for retrieving the error status and return status
of the asynchronous operation while it is in progress.
<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 must not modify the
<b>aiocb</b>
structure while the structure is being used by the system for
asynchronous I/O.
<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
<i><a href="read.html">read()</a></i>,
<i><a href="write.html">write()</a></i>,
or
<i><a href="fsync.html">fsync()</a></i>
call would have returned.
When the error status is not equal to EINPROGRESS,
the return status
reflects the return status of the corresponding synchronous operation.
<h4><a name = "tag_000_008_003">&nbsp;</a>Memory Management</h4>
Range memory locking and memory mapping operations are defined in
terms of pages.
Implementations may restrict the size and alignment
of range lockings and 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>
Memory locking guarantees the residence of portions of the address
space.  It is implementation-dependent
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
<i><a href="fork.html">fork()</a></i>,
and all memory locks owned by a process are unlocked upon
<i>exec</i>
or process termination.
Unmapping of an address range removes any memory locks
established on that address range by this process.
<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>
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.
<p>
An
<i><a href="unlink.html">unlink()</a></i>
of a file
or
<i><a href="shm_unlink.html">shm_unlink()</a></i>
of a shared memory object,
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>
Mapping may be restricted to disallow some types of access.
References to whole pages within the mapping
but beyond the current length of an object result in a
SIGBUS signal.
SIGBUS is used in this context to indicate an error using the object.
The size of the object is unaffected by access beyond the end of the
object.
Write attempts to memory that was mapped without write access,
or any access to memory mapped PROT_NONE,
results in a SIGSEGV signal.
SIGSEGV is used in this context to indicate a mapping error.
References to unmapped addresses result in a SIGSEGV signal.
<h4><a name = "tag_000_008_004">&nbsp;</a>Scheduling Policies</h4>
<p>
The scheduling semantics described in this specification 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 will result
if the sequencing of other resources takes
processor scheduling policy into account.
<p>
There is, conceptually, one thread list for each priority.
Any runnable thread may be on any thread list.
Multiple scheduling policies are 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>
Each process is controlled
by an associated scheduling policy and priority.
These parameters may be specified by explicit application execution of the
<i><a href="sched_setscheduler.html">sched_setscheduler()</a></i>
or
<i><a href="sched_setparam.html">sched_setparam()</a></i>
functions.
<p>
Each thread is controlled by an associated scheduling policy and
priority.  These parameters may be specified by explicit application
execution of the
<i><a href="pthread_setschedparam.html">pthread_setschedparam()</a></i>
function.
<p>
Associated with each policy is a priority range.
Each policy definition specifies
the minimum priority range for that policy.
The priority ranges for each policy may or may not overlap the priority ranges
of other policies.
<p>
A conforming implementation selects 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>
Three scheduling policies are specifically required.
Other implementation-dependent scheduling policies may be defined.
The following symbols are defined in the header
<i><a href="sched.h.html">&lt;sched.h&gt;</a></i>:
<div>
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Symbol</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>SCHED_FIFO
<td align=left>First in-first out (FIFO) scheduling policy.
<tr valign=top><td align=left>SCHED_RR
<td align=left>Round robin scheduling policy.
<tr valign=top><td align=left>SCHED_OTHER
<td align=left>Another scheduling policy.
</table>
</div>
<p>
The values of these symbols will be distinct.
<h5><a name = "tag_000_008_004_001">&nbsp;</a>SCHED_FIFO</h5>
Conforming implementations include a scheduling policy
called the FIFO scheduling policy.
<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>
Under the SCHED_FIFO
policy, the modification of the definitional thread lists is as follows:
<ol type = 1>
<p>
<li>
When a running thread becomes a preempted thread, it becomes the head
of the thread list for its priority.
<p>
<li>
When a blocked thread becomes a runnable thread, it becomes the tail
of the thread list for its priority.
<p>
<li>
When a running thread calls the
<i><a href="sched_setscheduler.html">sched_setscheduler()</a></i>
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>
When a running thread calls the
<i><a href="sched_setparam.html">sched_setparam()</a></i>
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>
When a running thread calls the
<i><a href="pthread_setschedparam.html">pthread_setschedparam()</a></i>
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>
If a thread whose policy or priority has been modified is a running
thread or is runnable, it then becomes the tail of the thread list for
its new priority.
<p>
<li>
When a running thread issues the
<i><a href="sched_yield.html">sched_yield()</a></i>
function,
the thread becomes the tail of the thread list for its priority.
<p>
<li>
At no other time will the position of a thread with this scheduling policy
within the thread lists be affected.
<p>
</ol>
<p>
For this policy, valid priorities shall be within the range returned by the
function
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_FIFO
is provided as the parameter.
Conforming implementations provide a priority range of at least 32
priorities for this policy.
<h5><a name = "tag_000_008_004_002">&nbsp;</a>SCHED_RR</h5>
<p>
Conforming implementations include a scheduling policy called the
round robin scheduling policy.
This policy is 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 function
<i><a href="sched_rr_get_interval.html">sched_rr_get_interval()</a></i>
or longer,
the thread becomes the tail of its thread list
and the head of that thread list is removed and made a running thread.
<p>
The effect of this policy is to ensure that if there are
multiple SCHED_RR threads at the same priority,
one of them will not monopolise 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>
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>
For this policy, valid priorities will be within the range
returned by the functions
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_RR is provided as the parameter.
Conforming implementations will provide a priority range of at least 32
priorities for this policy.
<h5><a name = "tag_000_008_004_003">&nbsp;</a>SCHED_OTHER</h5>
<p>
Conforming implementations 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 or SCHED_RR
is implementation-dependent.
<p>
This policy is defined to allow conforming applications to be able
to indicate that they no longer need a realtime scheduling policy
in a portable manner.
<p>
For threads executing under this policy,
the implementation uses only priorities within the range returned by the
functions
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_OTHER
is provided as the parameter.
<h4><a name = "tag_000_008_005">&nbsp;</a>Clocks and Timers</h4>
The header file
<i><a href="time.h.html">&lt;time.h&gt;</a></i>
defines the types and manifest constants used by the timing facility.
<h5><a name = "tag_000_008_005_001">&nbsp;</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><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>time_t
<td align=left>tv_sec
<td align=left>Seconds
<tr valign=top><td align=left>long
<td align=left>tv_nsec
<td align=left>Nanoseconds
</table>
<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'-.4m'<small>9</small>'.4m' + <i>tv_nsec</i>)
nanoseconds.
<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><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>struct timespec
<td align=left>it_interval
<td align=left>Timer period
<tr valign=top><td align=left>struct timespec
<td align=left>it_value
<td align=left>Timer expiration
</table>
<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 is disarmed.
<p>
If the value described by
<i>it_interval</i>
is non-zero, it specifies an interval to 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 will be disarmed after its next expiration; that is, a
one-shot timer is specified.
<h5><a name = "tag_000_008_005_002">&nbsp;</a>Timer Event Notification Control Block</h5>
<p>
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
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>,
is used in creating such a timer.
The
<b>sigevent</b>
structure contains the signal number and an application-specific data value
to be used when notifying
the calling process of timer expiration events.
<h5><a name = "tag_000_008_005_003">&nbsp;</a>Manifest Constants</h5>
<p>
The following constants are defined in
<i><a href="time.h.html">&lt;time.h&gt;</a></i>:
<dl compact>

<dt>CLOCK_REALTIME<dd>
The identifier for the systemwide realtime clock.

<dt>TIMER_ABSTIME<dd>
Flag indicating time is absolute
with respect to the clock associated with a timer.

</dl>
<p>
The maximum allowable resolution for the CLOCK_REALTIME
clock and all timers based on this clock, including the
<i><a href="nanosleep.html">nanosleep()</a></i>
function, is represented by {_POSIX_CLOCKRES_MIN}
and is defined as 20 ms (1/50 of a second).
Implementations may support smaller values of resolution for the
CLOCK_REALTIME clock to provide finer granularity time bases.
<p>
The minimum allowable maximum value for the CLOCK_REALTIME
clock and absolute timers based on it
is the same as that defined by the ISO C standard for the
<i>time_t</i>
type.
</blockquote><hr size=2 noshade>
<center><font size=2>
UNIX &reg; is a registered Trademark of The Open Group.<br>
Copyright &copy; 1997 The Open Group
<br> [ <a href="../index.html">Main Index</a> | <a href="../xshix.html">XSH</a> | <a href="../xcuix.html">XCU</a> | <a href="../xbdix.html">XBD</a> | <a href="../cursesix.html">XCURSES</a> | <a href="../xnsix.html">XNS</a> ]

</font></center><hr size=2 noshade>
</body></html>