From owner-freebsd-current Tue Oct 20 21:37:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA15093 for freebsd-current-outgoing; Tue, 20 Oct 1998 21:37:14 -0700 (PDT) (envelope-from owner-freebsd-current@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 VAA15088 for ; Tue, 20 Oct 1998 21:37:11 -0700 (PDT) (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 GAA22810; Wed, 21 Oct 1998 06:36:43 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA18955; Wed, 21 Oct 1998 06:36:36 +0200 (MET DST) Message-ID: <19981021063635.42023@follo.net> Date: Wed, 21 Oct 1998 06:36:35 +0200 From: Eivind Eklund To: Daniel Eischen , jasone@canonware.com, lists@tar.com Cc: current@FreeBSD.ORG Subject: Re: Another Serious libc_r problem References: <199810210220.WAA06394@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199810210220.WAA06394@pcnet1.pcnet.com>; from Daniel Eischen on Tue, Oct 20, 1998 at 10:20:12PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Oct 20, 1998 at 10:20:12PM -0400, Daniel Eischen wrote: > > >The point I was trying to make is that the > > >code does _not_ deadlock for the default (fast mutex). > > > > Yes, I missed your point. > > > > >I'm not sure that > > >this is a bug, but it is different than the behavior I've seen on other > > >systems. Can someone say whether this is allowed by the POSIX spec? > > POSIX says that "an attempt by the current owner of a mutex to relock > the mutex results in undefined behaviour". It also says that if > the current thread already owns the mutex, then EDEADLK should > be returned. I don't see any kind of counting mutex in the POSIX > spec. It can't say both (not without being ambiguous, anyway). Which one is it? I'm modifying that code and will have to run full tests on it anyway, so fixing this at the same time wouldn't hurt (actually, it would be a one-line change to sources I presently have - they already support both PTHREAD_MUTEX_DEFAULT (which is equal to the present implementation of MUTEX_TYPE_FAST), PTHREAD_MUTEX_NORMAL (which deadlock on locking against itself), and PTHREAD_MUTEX_ERRORCHECK (which return EDEADLK)). As soon as somebody can describe the wanted semantics (preferably with the appropriate quotes from the standard, I'll fix it. I don't have the relevant POSIX standard itself, so I can't just look it up :-/ > It seems our pthread_mutex_lock() is wrong, and should return > EDEADLK in this case. Sounds somewhat reasonable. However, if this is a requirement of POSIX, then SS2 has specified more relaxed restrictions than POSIX... Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message