summaryrefslogtreecommitdiff
path: root/mutex.c
diff options
context:
space:
mode:
authorrpj <rpj>2001-06-05 02:29:09 +0000
committerrpj <rpj>2001-06-05 02:29:09 +0000
commite0fcbebd9df209452022378d54c13344b4167d29 (patch)
tree202792df03a95548a7face67758100dc64f24d36 /mutex.c
parent40a9ee95108885c4a33fc035e0f17f46af9749de (diff)
Update some comments.
Diffstat (limited to 'mutex.c')
-rw-r--r--mutex.c12
1 files changed, 8 insertions, 4 deletions
diff --git a/mutex.c b/mutex.c
index 6c64cd5..086c0bc 100644
--- a/mutex.c
+++ b/mutex.c
@@ -174,15 +174,19 @@ pthread_mutex_destroy(pthread_mutex_t *mutex)
result = pthread_mutex_trylock(&mx);
+ /*
+ * 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?
+ */
if (result == 0 || pthread_equal( mx->ownerThread, pthread_self() ) )
{
-
/*
* FIXME!!!
* The mutex isn't held by another thread but we could still
- * be too late invalidating the mutex below. Yet we can't do it
- * earlier in case another thread needs to unlock the mutex
- * that it's holding.
+ * be too late invalidating the mutex below since another thread
+ * may alredy have entered mutex_lock and the check for a valid
+ * *mutex != NULL.
*/
*mutex = NULL;