vxwsem.html

来自「vxworks相关论文」· HTML 代码 · 共 749 行 · 第 1/3 页

a semaphore is given by a task that did not take it, mutual
exclusion could be lost.
<p>
</blockquote><h4>SYNCHRONIZATION</h4><blockquote><p>
To use a binary semaphore as a means of synchronization, create it
with an initial state of empty.  A task blocks by taking a
semaphore at a synchronization point, and it remains blocked until
the semaphore is given by another task or interrupt service
routine.
<p>
Synchronization with interrupt service routines is a particularly
common need.  Binary semaphores can be given, but not taken, from
interrupt level.  Thus, a task can block at a synchronization point
with <b><i><a href="./VXWSem.html#VXWSem::take">VXWSem::take</a></i>(&nbsp;)</b>, and an interrupt service routine can unblock
that task with <b><i><a href="./VXWSem.html#VXWSem::give">VXWSem::give</a></i>(&nbsp;)</b>.
<p>
A <b><i><a href="./semLib.html#semFlush">semFlush</a></i>(&nbsp;)</b> on a binary semaphore atomically unblocks all pended
tasks in the semaphore queue; that is, all tasks are unblocked at once,
before any actually execute.
<p>
</blockquote><h4>CAVEATS</h4><blockquote><p>
There is no mechanism to give back or reclaim semaphores automatically when
tasks are suspended or deleted.  Such a mechanism, though desirable, is not
currently feasible.  Without explicit knowledge of the state of the guarded
resource or region, reckless automatic reclamation of a semaphore could
leave the resource in a partial state.  Thus, if a task ceases execution
unexpectedly, as with a bus error, currently owned semaphores will not be
given back, effectively leaving a resource permanently unavailable.  The
mutual-exclusion semaphores provided by <b>VXWMSem</b> offer protection from
unexpected task deletion.
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
N/A
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./VXWSem.html#top">VXWSem</a></b>

<hr>
<a name="VXWMSem::VXWMSem"></a>
<p align=right>
<a href="rtnIndex.html"><i>Wind Foundation Classes :  Methods</i></a></p>

</blockquote><h1><i>VXWMSem::VXWMSem</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>VXWMSem::VXWMSem</i>(&nbsp;)</strong> - create and initialize a mutual-exclusion semaphore</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>VXWMSem
    (
    int opts
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine allocates and initializes a mutual-exclusion semaphore.  The
semaphore state is initialized to full.
<p>
Semaphore options include the following:
<dl>
<dt>
<b>SEM_Q_PRIORITY</b>
<dd>

Queue pended tasks on the basis of their priority.
<p>
<dt>
<b>SEM_Q_FIFO</b>
<dd>

Queue pended tasks on a first-in-first-out basis.
<p>
<dt>
<b>SEM_DELETE_SAFE</b>
<dd>

Protect a task that owns the semaphore from unexpected deletion.
This option enables an implicit <b><i><a href="./taskLib.html#taskSafe">taskSafe</a></i>(&nbsp;)</b> for each <b><i><a href="./VXWSem.html#VXWSem::take">VXWSem::take</a></i>(&nbsp;)</b>,
and an implicit <b><i><a href="./taskLib.html#taskUnsafe">taskUnsafe</a></i>(&nbsp;)</b> for each <b><i><a href="./VXWSem.html#VXWSem::give">VXWSem::give</a></i>(&nbsp;)</b>.
<p>
<dt>
<b>SEM_INVERSION_SAFE</b>
<dd>
 Protect the system from priority inversion.  With this option, the
task owning the semaphore executes at the highest priority of the
tasks pended on the semaphore, if that is higher than its current
priority.  This option must be accompanied by the <b>SEM_Q_PRIORITY</b>
queuing mode. 
</dl>

<p>

Mutual-exclusion semaphores offer convenient options suited for
situations that require mutually exclusive access to resources.
Typical applications include sharing devices and protecting data
structures.  Mutual-exclusion semaphores are used by many
higher-level VxWorks facilities.
<p>
The mutual-exclusion semaphore is a specialized version of the
binary semaphore, designed to address issues inherent in mutual
exclusion, such as recursive access to resources, priority
inversion, and deletion safety.  The fundamental behavior of the
mutual-exclusion semaphore is identical to the binary semaphore as
described for <b><i><a href="./VXWSem.html#VXWBSem::VXWBSem">VXWBSem::VXWBSem</a></i>(&nbsp;)</b>, except for the following
restrictions:
<p>
<ul>
<li>  It can only be used for mutual exclusion.</li>
<li>  It can only be given by the task that took it.</li>
<li>  It may not be taken or given from interrupt level.</li>
<li>   The <b><i><a href="./VXWSem.html#VXWSem::flush">VXWSem::flush</a></i>(&nbsp;)</b> operation is illegal. 
</ul>

<p>

<p>
These last two operations have no meaning in mutual-exclusion situations.
<p>
</blockquote><h4>RECURSIVE RESOURCE ACCESS</h4><blockquote><p>
<p>
A special feature of the mutual-exclusion semaphore is that it may
be taken "recursively;" that is, it can be taken more than once by
the task that owns it before finally being released.  Recursion is
useful for a set of routines that need mutually exclusive access to
a resource, but may need to call each other.
<p>
Recursion is possible because the system keeps track of which task
currently owns a mutual-exclusion semaphore.  Before being
released, a mutual-exclusion semaphore taken recursively must be
given the same number of times it has been taken; this is tracked
by means of a count which increments with each <b><i><a href="./VXWSem.html#VXWSem::take">VXWSem::take</a></i>(&nbsp;)</b>
and decrements with each <b><i><a href="./VXWSem.html#VXWSem::give">VXWSem::give</a></i>(&nbsp;)</b>.
<p>
</blockquote><h4>PRIORITY-INVERSION SAFETY</h4><blockquote><p>
If the option <b>SEM_INVERSION_SAFE</b> is selected, the library adopts a
priority-inheritance protocol to resolve potential occurrences of
"priority inversion," a problem stemming from the use semaphores for
mutual exclusion.  Priority inversion arises when a higher-priority task
is forced to wait an indefinite period of time for the completion of a
lower-priority task.
<p>
Consider the following scenario: T1, T2, and T3 are tasks of high,
medium, and low priority, respectively.  T3 has acquired some
resource by taking its associated semaphore.  When T1 preempts T3
and contends for the resource by taking the same semaphore, it
becomes blocked.  If we could be assured that T1 would be blocked
no longer than the time it normally takes T3 to finish with the
resource, the situation would not be problematic.  However, the
low-priority task is vulnerable to preemption by medium-priority
tasks; a preempting task, T2, could inhibit T3 from relinquishing
the resource.  This condition could persist, blocking T1 for an
indefinite period of time.
<p>
The priority-inheritance protocol solves the problem of priority
inversion by elevating the priority of T3 to the priority of T1
during the time T1 is blocked on T3.  This protects T3, and
indirectly T1, from preemption by T2.  Stated more generally, the
priority-inheritance protocol assures that a task which owns a
resource executes at the priority of the highest priority task
blocked on that resource.  When execution is complete, the task
gives up the resource and returns to its normal, or standard,
priority.  Hence, the "inheriting" task is protected from
preemption by any intermediate-priority tasks.
<p>
The priority-inheritance protocol also takes into consideration a task's
ownership of more than one mutual-exclusion semaphore at a time.  Such a
task will execute at the priority of the highest priority task blocked on
any of the resources it owns.  The task returns to its normal priority
only after relinquishing all of its mutual-exclusion semaphores that have
the inversion-safety option enabled.
<p>
</blockquote><h4>SEMAPHORE DELETION</h4><blockquote><p>
The <b><i><a href="./VXWSem.html#VXWSem::~VXWSem">VXWSem::~VXWSem</a></i>(&nbsp;)</b> destructor terminates a semaphore and deallocates any
associated memory.  The deletion of a semaphore unblocks tasks pended
on that semaphore; the routines which were pended return ERROR.  Take
special care when deleting mutual-exclusion semaphores to avoid
deleting a semaphore out from under a task that already owns (has
taken) that semaphore.  Applications should adopt the protocol of only
deleting semaphores that the deleting task owns.
<p>
</blockquote><h4>TASK-DELETION SAFETY</h4><blockquote><p>
If the option <b>SEM_DELETE_SAFE</b> is selected, the task owning the semaphore
is protected from deletion as long as it owns the semaphore.  This
solves another problem endemic to mutual exclusion.  Deleting a task
executing in a critical region can be catastrophic.  The resource could be
left in a corrupted state and the semaphore guarding the resource would be
unavailable, effectively shutting off all access to the resource.
<p>
As discussed in <b><a href="./taskLib.html#top">taskLib</a></b>, the primitives <b><i><a href="./taskLib.html#taskSafe">taskSafe</a></i>(&nbsp;)</b> and <b><i><a href="./taskLib.html#taskUnsafe">taskUnsafe</a></i>(&nbsp;)</b>
offer one solution, but as this type of protection goes hand in
hand with mutual exclusion, the mutual-exclusion semaphore provides
the option <b>SEM_DELETE_SAFE</b>, which enables an implicit <b><i><a href="./taskLib.html#taskSafe">taskSafe</a></i>(&nbsp;)</b>
with each <b><i><a href="./VXWSem.html#VXWSem::take">VXWSem::take</a></i>(&nbsp;)</b>, and a <b><i><a href="./taskLib.html#taskUnsafe">taskUnsafe</a></i>(&nbsp;)</b> with each
<b><i><a href="./VXWSem.html#VXWSem::give">VXWSem::give</a></i>(&nbsp;)</b>.  This convenience is also more efficient, as the
resulting code requires fewer entrances to the kernel.
<p>
</blockquote><h4>CAVEATS</h4><blockquote><p>
There is no mechanism to give back or reclaim semaphores automatically when
tasks are suspended or deleted.  Such a mechanism, though desirable, is not
currently feasible.  Without explicit knowledge of the state of the guarded
resource or region, reckless automatic reclamation of a semaphore could
leave the resource in a partial state.  Thus if a task ceases execution
unexpectedly, as with a bus error, currently owned semaphores will not be
given back, effectively leaving a resource permanently unavailable.  The
<b>SEM_DELETE_SAFE</b> option partially protects an application, to the extent
that unexpected deletions will be deferred until the resource is released.
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
N/A
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./VXWSem.html#top">VXWSem</a></b>, <b><i><a href="./taskLib.html#taskSafe">taskSafe</a></i>(&nbsp;)</b>, <b><i><a href="./taskLib.html#taskUnsafe">taskUnsafe</a></i>(&nbsp;)</b>

<hr>
<a name="VXWMSem::giveForce"></a>
<p align=right>
<a href="rtnIndex.html"><i>Wind Foundation Classes :  Methods</i></a></p>

</blockquote><h1><i>VXWMSem::giveForce</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>VXWMSem::giveForce</i>(&nbsp;)</strong> - give a mutual-exclusion semaphore without restrictions</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>    STATUS giveForce ()</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine gives a mutual-exclusion semaphore, regardless of semaphore
ownership.  It is intended as a debugging aid only.
<p>
The routine is particularly useful when a task dies while holding some
mutual-exclusion semaphore, because the semaphore can be resurrected.  The
routine gives the semaphore to the next task in the pend queue, or makes
the semaphore full if no tasks are pending.  In effect, execution 
continues as if the task owning the semaphore had actually given the
semaphore.
<p>
</blockquote><h4>CAVEATS</h4><blockquote><p>
Use this routine should only as a debugging aid, when the condition of
the semaphore is known.
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
OK.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><i><a href="./VXWSem.html#VXWSem::give">VXWSem::give</a></i>(&nbsp;)</b>

</body>
</html>