359 lines
18 KiB
HTML
359 lines
18 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>pthread_mutex_destroy</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="pthread_mutex_destroy"></a> <a name="tag_03_537"></a><!-- pthread_mutex_destroy -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_537_01"></a>NAME</h4>
|
|
|
|
<blockquote>pthread_mutex_destroy, pthread_mutex_init - destroy and initialize a mutex</blockquote>
|
|
|
|
<h4><a name="tag_03_537_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<div class="box"><code><tt><sup>[<a href="javascript:open_code('THR')">THR</a>]</sup> <img src="../images/opt-start.gif" alt=
|
|
"[Option Start]" border="0"> #include <<a href="../basedefs/pthread.h.html">pthread.h</a>><br>
|
|
<br>
|
|
int pthread_mutex_destroy(pthread_mutex_t *</tt><i>mutex</i><tt>);<br>
|
|
int pthread_mutex_init(pthread_mutex_t *restrict</tt> <i>mutex</i><tt>,<br>
|
|
const pthread_mutexattr_t *restrict</tt> <i>attr</i><tt>);<br>
|
|
pthread_mutex_t</tt> <i>mutex</i> <tt>= PTHREAD_MUTEX_INITIALIZER; <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></tt></code></div>
|
|
|
|
<tt><br>
|
|
</tt></blockquote>
|
|
|
|
<h4><a name="tag_03_537_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>pthread_mutex_destroy</i>() function shall destroy the mutex object referenced by <i>mutex</i>; the mutex object becomes,
|
|
in effect, uninitialized. An implementation may cause <i>pthread_mutex_destroy</i>() to set the object referenced by <i>mutex</i>
|
|
to an invalid value. A destroyed mutex object can be reinitialized using <i>pthread_mutex_init</i>(); the results of otherwise
|
|
referencing the object after it has been destroyed are undefined.</p>
|
|
|
|
<p>It shall be safe to destroy an initialized mutex that is unlocked. Attempting to destroy a locked mutex results in undefined
|
|
behavior.</p>
|
|
|
|
<p>The <i>pthread_mutex_init</i>() function shall initialize the mutex referenced by <i>mutex</i> with attributes specified by
|
|
<i>attr</i>. If <i>attr</i> is NULL, the default mutex attributes are used; the effect shall be the same as passing the address of
|
|
a default mutex attributes object. Upon successful initialization, the state of the mutex becomes initialized and unlocked.</p>
|
|
|
|
<p>Only <i>mutex</i> itself may be used for performing synchronization. The result of referring to copies of <i>mutex</i> in calls
|
|
to <a href="../functions/pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a>, <a href=
|
|
"../functions/pthread_mutex_trylock.html"><i>pthread_mutex_trylock</i>()</a>, <a href=
|
|
"../functions/pthread_mutex_unlock.html"><i>pthread_mutex_unlock</i>()</a>, and <i>pthread_mutex_destroy</i>() is undefined.</p>
|
|
|
|
<p>Attempting to initialize an already initialized mutex results in undefined behavior.</p>
|
|
|
|
<p>In cases where default mutex attributes are appropriate, the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize mutexes
|
|
that are statically allocated. The effect shall be equivalent to dynamic initialization by a call to <i>pthread_mutex_init</i>()
|
|
with parameter <i>attr</i> specified as NULL, except that no error checks are performed.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_04"></a>RETURN VALUE</h4>
|
|
|
|
<blockquote>
|
|
<p>If successful, the <i>pthread_mutex_destroy</i>() and <i>pthread_mutex_init</i>() functions shall return zero; otherwise, an
|
|
error number shall be returned to indicate the error.</p>
|
|
|
|
<p>The [EBUSY] and [EINVAL] error checks, if implemented, act as if they were performed immediately at the beginning of processing
|
|
for the function and shall cause an error return prior to modifying the state of the mutex specified by <i>mutex</i>.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_05"></a>ERRORS</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>pthread_mutex_destroy</i>() function may fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EBUSY]</dt>
|
|
|
|
<dd>The implementation has detected an attempt to destroy the object referenced by <i>mutex</i> while it is locked or referenced
|
|
(for example, while being used in a <a href="../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a> or <a
|
|
href="../functions/pthread_cond_wait.html"><i>pthread_cond_wait</i>()</a>) by another thread.</dd>
|
|
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>The value specified by <i>mutex</i> is invalid.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>pthread_mutex_init</i>() function shall fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EAGAIN]</dt>
|
|
|
|
<dd>The system lacked the necessary resources (other than memory) to initialize another mutex.</dd>
|
|
|
|
<dt>[ENOMEM]</dt>
|
|
|
|
<dd>Insufficient memory exists to initialize the mutex.</dd>
|
|
|
|
<dt>[EPERM]</dt>
|
|
|
|
<dd>The caller does not have the privilege to perform the operation.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>pthread_mutex_init</i>() function may fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EBUSY]</dt>
|
|
|
|
<dd>The implementation has detected an attempt to reinitialize the object referenced by <i>mutex</i>, a previously initialized, but
|
|
not yet destroyed, mutex.</dd>
|
|
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>The value specified by <i>attr</i> is invalid.</dd>
|
|
</dl>
|
|
|
|
<p>These functions shall not return an error code of [EINTR].</p>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<div class="box"><em>The following sections are informative.</em></div>
|
|
|
|
<h4><a name="tag_03_537_06"></a>EXAMPLES</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_07"></a>APPLICATION USAGE</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_08"></a>RATIONALE</h4>
|
|
|
|
<blockquote>
|
|
<h5><a name="tag_03_537_08_01"></a>Alternate Implementations Possible</h5>
|
|
|
|
<p>This volume of IEEE Std 1003.1-2001 supports several alternative implementations of mutexes. An implementation may
|
|
store the lock directly in the object of type <b>pthread_mutex_t</b>. Alternatively, an implementation may store the lock in the
|
|
heap and merely store a pointer, handle, or unique ID in the mutex object. Either implementation has advantages or may be required
|
|
on certain hardware configurations. So that portable code can be written that is invariant to this choice, this volume of
|
|
IEEE Std 1003.1-2001 does not define assignment or equality for this type, and it uses the term "initialize" to
|
|
reinforce the (more restrictive) notion that the lock may actually reside in the mutex object itself.</p>
|
|
|
|
<p>Note that this precludes an over-specification of the type of the mutex or condition variable and motivates the opaqueness of
|
|
the type.</p>
|
|
|
|
<p>An implementation is permitted, but not required, to have <i>pthread_mutex_destroy</i>() store an illegal value into the mutex.
|
|
This may help detect erroneous programs that try to lock (or otherwise reference) a mutex that has already been destroyed.</p>
|
|
|
|
<h5><a name="tag_03_537_08_02"></a>Tradeoff Between Error Checks and Performance Supported</h5>
|
|
|
|
<p>Many of the error checks were made optional in order to let implementations trade off performance <i>versus</i> degree of error
|
|
checking according to the needs of their specific applications and execution environment. As a general rule, errors or conditions
|
|
caused by the system (such as insufficient memory) always need to be reported, but errors due to an erroneously coded application
|
|
(such as failing to provide adequate synchronization to prevent a mutex from being deleted while in use) are made optional.</p>
|
|
|
|
<p>A wide range of implementations is thus made possible. For example, an implementation intended for application debugging may
|
|
implement all of the error checks, but an implementation running a single, provably correct application under very tight
|
|
performance constraints in an embedded computer might implement minimal checks. An implementation might even be provided in two
|
|
versions, similar to the options that compilers provide: a full-checking, but slower version; and a limited-checking, but faster
|
|
version. To forbid this optionality would be a disservice to users.</p>
|
|
|
|
<p>By carefully limiting the use of "undefined behavior" only to things that an erroneous (badly coded) application might do, and
|
|
by defining that resource-not-available errors are mandatory, this volume of IEEE Std 1003.1-2001 ensures that a
|
|
fully-conforming application is portable across the full range of implementations, while not forcing all implementations to add
|
|
overhead to check for numerous things that a correct program never does.</p>
|
|
|
|
<h5><a name="tag_03_537_08_03"></a>Why No Limits are Defined</h5>
|
|
|
|
<p>Defining symbols for the maximum number of mutexes and condition variables was considered but rejected because the number of
|
|
these objects may change dynamically. Furthermore, many implementations place these objects into application memory; thus, there is
|
|
no explicit maximum.</p>
|
|
|
|
<h5><a name="tag_03_537_08_04"></a>Static Initializers for Mutexes and Condition Variables</h5>
|
|
|
|
<p>Providing for static initialization of statically allocated synchronization objects allows modules with private static
|
|
synchronization variables to avoid runtime initialization tests and overhead. Furthermore, it simplifies the coding of
|
|
self-initializing modules. Such modules are common in C libraries, where for various reasons the design calls for
|
|
self-initialization instead of requiring an explicit module initialization function to be called. An example use of static
|
|
initialization follows.</p>
|
|
|
|
<p>Without static initialization, a self-initializing routine <i>foo</i>() might look as follows:</p>
|
|
|
|
<pre>
|
|
<tt>static pthread_once_t foo_once = PTHREAD_ONCE_INIT;
|
|
static pthread_mutex_t foo_mutex;
|
|
<br>
|
|
void foo_init()
|
|
{
|
|
pthread_mutex_init(&foo_mutex, NULL);
|
|
}
|
|
<br>
|
|
void foo()
|
|
{
|
|
pthread_once(&foo_once, foo_init);
|
|
pthread_mutex_lock(&foo_mutex);
|
|
/* Do work. */
|
|
pthread_mutex_unlock(&foo_mutex);
|
|
}
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>With static initialization, the same routine could be coded as follows:</p>
|
|
|
|
<pre>
|
|
<tt>static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;
|
|
<br>
|
|
void foo()
|
|
{
|
|
pthread_mutex_lock(&foo_mutex);
|
|
/* Do work. */
|
|
pthread_mutex_unlock(&foo_mutex);
|
|
}
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>Note that the static initialization both eliminates the need for the initialization test inside <a href=
|
|
"../functions/pthread_once.html"><i>pthread_once</i>()</a> and the fetch of &<i>foo_mutex</i> to learn the address to be passed
|
|
to <a href="../functions/pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a> or <a href=
|
|
"../functions/pthread_mutex_unlock.html"><i>pthread_mutex_unlock</i>()</a>.</p>
|
|
|
|
<p>Thus, the C code written to initialize static objects is simpler on all systems and is also faster on a large class of systems;
|
|
those where the (entire) synchronization object can be stored in application memory.</p>
|
|
|
|
<p>Yet the locking performance question is likely to be raised for machines that require mutexes to be allocated out of special
|
|
memory. Such machines actually have to have mutexes and possibly condition variables contain pointers to the actual hardware locks.
|
|
For static initialization to work on such machines, <a href="../functions/pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a>
|
|
also has to test whether or not the pointer to the actual lock has been allocated. If it has not, <a href=
|
|
"../functions/pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a> has to initialize it before use. The reservation of such
|
|
resources can be made when the program is loaded, and hence return codes have not been added to mutex locking and condition
|
|
variable waiting to indicate failure to complete initialization.</p>
|
|
|
|
<p>This runtime test in <a href="../functions/pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a> would at first seem to be
|
|
extra work; an extra test is required to see whether the pointer has been initialized. On most machines this would actually be
|
|
implemented as a fetch of the pointer, testing the pointer against zero, and then using the pointer if it has already been
|
|
initialized. While the test might seem to add extra work, the extra effort of testing a register is usually negligible since no
|
|
extra memory references are actually done. As more and more machines provide caches, the real expenses are memory references, not
|
|
instructions executed.</p>
|
|
|
|
<p>Alternatively, depending on the machine architecture, there are often ways to eliminate <i>all</i> overhead in the most
|
|
important case: on the lock operations that occur <i>after</i> the lock has been initialized. This can be done by shifting more
|
|
overhead to the less frequent operation: initialization. Since out-of-line mutex allocation also means that an address has to be
|
|
dereferenced to find the actual lock, one technique that is widely applicable is to have static initialization store a bogus value
|
|
for that address; in particular, an address that causes a machine fault to occur. When such a fault occurs upon the first attempt
|
|
to lock such a mutex, validity checks can be done, and then the correct address for the actual lock can be filled in. Subsequent
|
|
lock operations incur no extra overhead since they do not "fault". This is merely one technique that can be used to support
|
|
static initialization, while not adversely affecting the performance of lock acquisition. No doubt there are other techniques that
|
|
are highly machine-dependent.</p>
|
|
|
|
<p>The locking overhead for machines doing out-of-line mutex allocation is thus similar for modules being implicitly initialized,
|
|
where it is improved for those doing mutex allocation entirely inline. The inline case is thus made much faster, and the
|
|
out-of-line case is not significantly worse.</p>
|
|
|
|
<p>Besides the issue of locking performance for such machines, a concern is raised that it is possible that threads would serialize
|
|
contending for initialization locks when attempting to finish initializing statically allocated mutexes. (Such finishing would
|
|
typically involve taking an internal lock, allocating a structure, storing a pointer to the structure in the mutex, and releasing
|
|
the internal lock.) First, many implementations would reduce such serialization by hashing on the mutex address. Second, such
|
|
serialization can only occur a bounded number of times. In particular, it can happen at most as many times as there are statically
|
|
allocated synchronization objects. Dynamically allocated objects would still be initialized via <i>pthread_mutex_init</i>() or <a
|
|
href="../functions/pthread_cond_init.html"><i>pthread_cond_init</i>()</a>.</p>
|
|
|
|
<p>Finally, if none of the above optimization techniques for out-of-line allocation yields sufficient performance for an
|
|
application on some implementation, the application can avoid static initialization altogether by explicitly initializing all
|
|
synchronization objects with the corresponding <i>pthread_*_init</i>() functions,
|
|
which are supported by all implementations. An implementation can also document the tradeoffs and advise which initialization
|
|
technique is more efficient for that particular implementation.</p>
|
|
|
|
<h5><a name="tag_03_537_08_05"></a>Destroying Mutexes</h5>
|
|
|
|
<p>A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:</p>
|
|
|
|
<pre>
|
|
<tt>struct obj {
|
|
pthread_mutex_t om;
|
|
int refcnt;
|
|
...
|
|
};
|
|
<br>
|
|
obj_done(struct obj *op)
|
|
{
|
|
pthread_mutex_lock(&op->om);
|
|
if (--op->refcnt == 0) {
|
|
pthread_mutex_unlock(&op->om);
|
|
(A) pthread_mutex_destroy(&op->om);
|
|
(B) free(op);
|
|
} else
|
|
(C) pthread_mutex_unlock(&op->om);
|
|
}
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>In this case <i>obj</i> is reference counted and <i>obj_done</i>() is called whenever a reference to the object is dropped.
|
|
Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B)
|
|
immediately after the object is unlocked (line C).</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_09"></a>FUTURE DIRECTIONS</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_10"></a>SEE ALSO</h4>
|
|
|
|
<blockquote>
|
|
<p><a href="pthread_mutex_getprioceiling.html"><i>pthread_mutex_getprioceiling</i>()</a> , <a href=
|
|
"pthread_mutex_lock.html"><i>pthread_mutex_lock</i>()</a> , <a href=
|
|
"pthread_mutex_timedlock.html"><i>pthread_mutex_timedlock</i>()</a> , <a href=
|
|
"pthread_mutexattr_getpshared.html"><i>pthread_mutexattr_getpshared</i>()</a> , the Base Definitions volume of
|
|
IEEE Std 1003.1-2001, <a href="../basedefs/pthread.h.html"><i><pthread.h></i></a></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_11"></a>CHANGE HISTORY</h4>
|
|
|
|
<blockquote>
|
|
<p>First released in Issue 5. Included for alignment with the POSIX Threads Extension.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_537_12"></a>Issue 6</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>pthread_mutex_destroy</i>() and <i>pthread_mutex_init</i>() functions are marked as part of the Threads option.</p>
|
|
|
|
<p>The <a href="../functions/pthread_mutex_timedlock.html"><i>pthread_mutex_timedlock</i>()</a> function is added to the SEE ALSO
|
|
section for alignment with IEEE Std 1003.1d-1999.</p>
|
|
|
|
<p>IEEE PASC Interpretation 1003.1c #34 is applied, updating the DESCRIPTION.</p>
|
|
|
|
<p>The <b>restrict</b> keyword is added to the <i>pthread_mutex_init</i>() prototype for alignment with the ISO/IEC 9899:1999
|
|
standard.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|