Update some comments

This commit is contained in:
Gregory Nutt 2017-03-22 08:08:43 -06:00
parent f5a957158d
commit 5fb85451cb
2 changed files with 20 additions and 5 deletions

View File

@ -136,8 +136,13 @@ int pthread_mutex_lock(FAR pthread_mutex_t *mutex)
else
#endif
{
/* No, then we would deadlock... return an error (default behavior
* is like PTHREAD_MUTEX_ERRORCHECK)
/* No, then we would deadlock... return an error (default
* behavior is like PTHREAD_MUTEX_ERRORCHECK)
*
* NOTE: This is non-compliant behavior for the case of a
* NORMAL mutex. In that case, it the deadlock condition should
* not be detected and the thread should be permitted to
* deadlock.
*/
serr("ERROR: Returning EDEADLK\n");
@ -169,4 +174,3 @@ int pthread_mutex_lock(FAR pthread_mutex_t *mutex)
sinfo("Returning %d\n", ret);
return ret;
}

View File

@ -100,13 +100,22 @@ int pthread_mutex_unlock(FAR pthread_mutex_t *mutex)
if (mutex->pid != (int)getpid())
{
/* No... return an error (default behavior is like PTHREAD_MUTEX_ERRORCHECK) */
/* No... return an EPERM error.
*
* Per POSIX: "EPERM should be returned if the mutex type is
* PTHREAD_MUTEX_ERRORCHECK or PTHREAD_MUTEX_RECURSIVE, or the
* mutex is a robust mutex, and the current thread does not own
* the mutex."
*
* For the case of the non-robust PTHREAD_MUTEX_NORMAL mutex,
* the behavior is undefined. Here we treat that type as though
* it were PTHREAD_MUTEX_ERRORCHECK type and just return an error.
*/
serr("ERROR: Holder=%d returning EPERM\n", mutex->pid);
ret = EPERM;
}
/* Yes, the caller owns the semaphore.. Is this a recursive mutex? */
#ifdef CONFIG_MUTEX_TYPES
@ -116,6 +125,7 @@ int pthread_mutex_unlock(FAR pthread_mutex_t *mutex)
* the mutex lock, just decrement the count of locks held, and return
* success.
*/
mutex->nlocks--;
}
#endif
@ -134,6 +144,7 @@ int pthread_mutex_unlock(FAR pthread_mutex_t *mutex)
#endif
ret = pthread_givesemaphore((FAR sem_t *)&mutex->sem);
}
sched_unlock();
}