From owner-freebsd-bugs Mon Oct 23 21: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 63AF637B4C5 for ; Mon, 23 Oct 2000 21:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA31976; Mon, 23 Oct 2000 21:00:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 79E4937B479; Mon, 23 Oct 2000 20:53:10 -0700 (PDT) Message-Id: <20001024035310.79E4937B479@hub.freebsd.org> Date: Mon, 23 Oct 2000 20:53:10 -0700 (PDT) From: bruce@cubik.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: misc/22266: Possible departure from standards compliance in pthreads Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 22266 >Category: misc >Synopsis: Possible departure from standards compliance in pthreads >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 23 21:00:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Bruce Mitchener >Release: 3.2, 4.0 >Organization: >Environment: FreeBSD worlds-apart.com 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08 GMT 1999 jkh@cathair:/usr/src/sys/compile/GENERIC i386 FreeBSD ice 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 root@monster.cdrom.com:/usr/src/sys/compile/GENERIC i386 >Description: 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. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message