From owner-freebsd-hackers Sun Nov 29 12:01:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27997 for freebsd-hackers-outgoing; Sun, 29 Nov 1998 12:01:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27985; Sun, 29 Nov 1998 12:01:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id VAA10455; Sun, 29 Nov 1998 21:00:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA09070; Sun, 29 Nov 1998 21:00:47 +0100 (MET) Message-ID: <19981129210047.Z9226@follo.net> Date: Sun, 29 Nov 1998 21:00:47 +0100 From: Eivind Eklund To: Daniel Eischen Cc: hackers@FreeBSD.ORG, jb@FreeBSD.ORG, lists@tar.com Subject: Re: Thread locking (was Re: cvs commit: src/include pthread.h src/lib/libc_r/uthread uthread_mattr_kind_np.c uthread_mutex.c) References: <199811291714.MAA05445@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811291714.MAA05445@pcnet1.pcnet.com>; from Daniel Eischen on Sun, Nov 29, 1998 at 12:14:11PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 29, 1998 at 12:14:11PM -0500, Daniel Eischen wrote: > Eivind Eklund wrote: > > On Sun, Nov 29, 1998 at 09:31:18AM -0500, Daniel Eischen wrote: > > > The threads library is not fully POSIX compliant yet and has to > > > change if it wants to achieve that. POSIX says that we return > > > EDEADLK if we detect this condition (which we can and already do). > > > Do we care more about backwards compatibility or more about POSIX > > > compliance? I vote for strong and strict POSIX compliance (if my > > > vote counts at all ;-). > > > > I'm in two minds about it. I don't like breaking compatibility, and I > > don't like not being conformant, and it really comes down to each > > individual case. The behaviour we have now seems to be conformant to > > SS2, at least, which IMO is more important than POSIX. > > What does the P in Pthreads mean? Phenomenally stupid. Any standard that include locking and doesn't allow definition of recursive locks fall within this category. > Isn't SS2 based off an earlier rev (draft) of the POSIX spec? No - it is AFAIK a superset of the POSIX standard. It also require that if we detect the deadlock condition we should return EDEADLK - but we don't detect the case. Allowing a lock to be "re-aquired" by the same thread just falls out of the code. Another issue is that the standard isn't exactly internally consistent - it both require that a PTHREAD_MUTEX_NORMAL should deadlock if locked twice by the same thread, and that all deadlocks should return EDEADLK when detected. You _could_ construct this as 'PTHREAD_MUTEX_NORMAL should not detect deadlocks", but detecting deadlocks is the only way we can make it deadlock (and I consider dictating that it shouldn't detect is too much dictation of internal details, anyway). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message