From owner-freebsd-current Tue Oct 20 22:12:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA17182 for freebsd-current-outgoing; Tue, 20 Oct 1998 22:12:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA17176 for ; Tue, 20 Oct 1998 22:12:38 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id BAA19668; Wed, 21 Oct 1998 01:12:09 -0400 (EDT) Date: Wed, 21 Oct 1998 01:12:09 -0400 (EDT) From: Daniel Eischen Message-Id: <199810210512.BAA19668@pcnet1.pcnet.com> To: eischen@vigrid.com, eivind@yes.no, jasone@canonware.com, lists@tar.com Subject: Re: Another Serious libc_r problem Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund wrote: > 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? It does say both, but regarding the EDEADLK return value, it says "if the condition [thread already owns the mutex] is detected". So if the implementation were not to detect the condition, then I think "undefined behaviour" would occur. Since we can and do detect the condition, we should return EDEADLK in this case. > 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)). I don't see any of these in the POSIX spec, although I just got the spec and may have overlooked them. Are you also working on priority ceilings and inheritence? > 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 :-/ If you have questions ask me and I can look them up for you. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message