Bug 22266

Summary: Possible departure from standards compliance in pthreads
Product: Base System Reporter: bruce <bruce>
Component: miscAssignee: Jason Evans <jasone>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description bruce 2000-10-24 05:00:01 UTC
To the best of my understanding the Single Unix Specification v2 (Unix98) defines PTHREAD_MUTEX_DEFAULT to be PTHREAD_MUTEX_NORMAL (non-recursive, non-errorchecking).

That is the behavior used on Linux with GNU libc 2.1 and 2.2, as well as Solaris 7.  However, FreeBSD 3.2 and 4.0 (the only FreeBSD machines that I have around), define it to be PTHREAD_MUTEX_ERRORCHECK with this excerpt from /usr/include/pthread.h:
enum pthread_mutextype {
        PTHREAD_MUTEX_ERRORCHECK        = 1,    /* Default POSIX mutex */
        PTHREAD_MUTEX_RECURSIVE         = 2,    /* Recursive mutex */
        PTHREAD_MUTEX_NORMAL            = 3,    /* No error checking */
        MUTEX_TYPE_MAX
};

#define PTHREAD_MUTEX_DEFAULT           PTHREAD_MUTEX_ERRORCHECK

While on Linux with glibc 2.1, it looks like:

enum
{
  PTHREAD_MUTEX_FAST_NP,
  PTHREAD_MUTEX_RECURSIVE_NP,
  PTHREAD_MUTEX_ERRORCHECK_NP
#ifdef __USE_UNIX98
  ,
  PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_FAST_NP,
  PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
  PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
  PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
#endif
};

and on Solaris 7:
#define PTHREAD_MUTEX_NORMAL            0x0
#define PTHREAD_MUTEX_ERRORCHECK        0x2
#define PTHREAD_MUTEX_RECURSIVE         0x4
#define PTHREAD_MUTEX_DEFAULT           PTHREAD_MUTEX_NORMAL

A related man page from the Open Group:
http://www.opennc.org/onlinepubs/7908799/xsh/pthread_mutexattr_gettype.html

With the comment that:
  "Attempting to recursively lock a mutex of this type results in
  undefined behaviour. Attempting to unlock a mutex of this type
  which was not locked by the calling thread results in undefined
  behaviour. Attempting to unlock a mutex of this type which is
  not locked results in undefined behaviour. An implementation is
  allowed to map this mutex to one of the other mutex types."

So, while they aren't specific as to which it should be mapped to, most other implementations appear to favor mapping it to PTHREAD_MUTEX_NORMAL, and giving no behavior other than what is guaranteed within the specification.

Of course, anyone desiring guaranteed portable behavior can simply opt not to use PTHREAD_MUTEX_DEFAULT and use one of the others.
Comment 1 Jason Evans freebsd_committer freebsd_triage 2000-10-24 15:57:41 UTC
Responsible Changed
From-To: freebsd-bugs->jasone

Over to maintainer. 
Comment 2 Jason Evans freebsd_committer freebsd_triage 2000-11-07 02:57:34 UTC
State Changed
From-To: open->closed

SUSv2 specifically allows mapping PTHREAD_MUTEX_DEFAULT to one of the other 
required mutex types.  Therefore, this PR does not report a bug or standards 
non-compliance.