summaryrefslogtreecommitdiff
path: root/pthread_mutex_destroy.c
diff options
context:
space:
mode:
authorrpj <rpj>2002-02-20 06:33:47 +0000
committerrpj <rpj>2002-02-20 06:33:47 +0000
commit09cf57ffcf96b3f0cf7d5ec959c455ba54245a65 (patch)
tree7edd8561288890fcea3a731d3ea1997c0cac861b /pthread_mutex_destroy.c
parent0bd90e988f305e0d8e2e3ce6a844c204c4c7c436 (diff)
Changes to comments.
Diffstat (limited to 'pthread_mutex_destroy.c')
-rw-r--r--pthread_mutex_destroy.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/pthread_mutex_destroy.c b/pthread_mutex_destroy.c
index c9c1426..22d78a1 100644
--- a/pthread_mutex_destroy.c
+++ b/pthread_mutex_destroy.c
@@ -62,7 +62,7 @@ pthread_mutex_destroy(pthread_mutex_t *mutex)
/*
* The mutex type may not be RECURSIVE therefore trylock may return EBUSY if
* we already own the mutex. Here we are assuming that it's OK to destroy
- * a mutex that we own and have locked recursively. Is this correct?
+ * a mutex that we own and have locked recursively.
*
* For FAST mutexes we record the owner as ANONYMOUS for speed. In this
* case we assume that the thread calling pthread_mutex_destroy() is the
@@ -78,6 +78,10 @@ pthread_mutex_destroy(pthread_mutex_t *mutex)
* be too late invalidating the mutex below since another thread
* may already have entered mutex_lock and the check for a valid
* *mutex != NULL.
+ *
+ * Note that this would be an unusual situation because it is not
+ * common that mutexes are destroyed while they are still in
+ * use by other threads.
*/
*mutex = NULL;