Base WG Resolution Ref: bwg97-008
Topic: PTHREAD_MUTEX* extensions


This is an unapproved draft Base Working Group Resolution for XSH Issue 5 .

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