Date: Wed, 21 Oct 1998 12:20:19 +0200 From: Eivind Eklund <eivind@yes.no> To: Daniel Eischen <eischen@vigrid.com>, jasone@canonware.com, lists@tar.com Cc: current@FreeBSD.ORG Subject: Re: Another Serious libc_r problem Message-ID: <19981021122019.33548@follo.net> In-Reply-To: <199810210512.BAA19668@pcnet1.pcnet.com>; from Daniel Eischen on Wed, Oct 21, 1998 at 01:12:09AM -0400 References: <199810210512.BAA19668@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 21, 1998 at 01:12:09AM -0400, Daniel Eischen wrote: > Eivind Eklund wrote: > > On Tue, Oct 20, 1998 at 10:20:12PM -0400, Daniel Eischen wrote: > > > 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. Yeah, I think I agree. However, it may shock FreeBSD-specific threaded programs. Well, "gratious implementation knowledge" and all that. > > 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. They would be described in the section for pthread_mutexattr_settype() if they are there at all. These are different types of locks - you can see the descriptions of them at http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_settype.html > Are you also working on priority ceilings and inheritence? No. I started doing the changes because one of my co-workers' programs needed recursive locks, and we try to write to the SS2 API. > > 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. Exact definition of how the locks are supposed to work (the relevant quotes, not just from memory) would be very nice. If you have time, just cross-referencing with SS2 and telling about the differences would probably be what makes things easiest. (I can't promise to spend much time on this - what I was doing was just random maintenance due to it being required locally - my present 'pet project' for FreeBSD is something else). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981021122019.33548>