Last update: 09 October,1997
97 #008 _____________________________________________________________________________ Topic: PTHREAD_MUTEX* extensions Relevant Sections: pthread_mutex_trylock Spec: XSH Issue 5 Resolution Request: ------------------- The UNIX98 spec extends POSIX96 with a PTHREAD_MUTEX_RECURSIVE mutex type. How should pthread_mutex_trylock() behave when the caller already owns a lock on a mutex of this type ? The description of PTHREAD_MUTEX_RECURSIVE on page 646 appears to conflict with the requirement on page 636 that pthread_mutex_trylock() return EBUSY when the mutex is already locked. The UNIX98 spec also extends POSIX96 with a PTHREAD_MUTEX_DEFAULT mutex type and the pthread_mutexattr_[sg]ettype() interface. What can portable POSIX96 applications assume about the behavior of mutexes in the absence of an application call to the pthread_mutexattr_settype() function and the statement on page 646 allowing an implementation to map this type to one of the other mutex types ? Resolution Response ------------------- Rationale ------------- None. Circulated for review: Oct 9 1997