Date: Sun, 29 Nov 1998 16:14:18 +0100 From: Eivind Eklund <eivind@yes.no> To: Daniel Eischen <eischen@vigrid.com> 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) Message-ID: <19981129161418.W9226@follo.net> In-Reply-To: <199811291431.JAA22106@pcnet1.pcnet.com>; from Daniel Eischen on Sun, Nov 29, 1998 at 09:31:18AM -0500 References: <199811291431.JAA22106@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 29, 1998 at 09:31:18AM -0500, Daniel Eischen wrote: > > On Sat, Nov 28, 1998 at 09:31:16PM -0500, Daniel Eischen wrote: > > > And can we also make a default mutex an error checking mutex? > > > > Not easily. The problem is that the default type of locks we've used > > before are more forgiving - they e.g. allow a thread to lock a lock > > several times (without deadlocking), and then release it by the first > > pthread_unlock(). > > So what? It means that at least our own code has to be reviewed before making this change. > 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. I'm not the maintainer, anyway, so I don't consider it within my authority to break backwards compatibility. > > > If at all possible, we should let the programmer know that he's > > > hit a deadlock condition. > > > > He won't hit a deadlock on the default type now. The default type > > doesn't really correspond to any of the SS2 types - I had to manually > > add a deadlock to support PTHREAD_MUTEX_NORMAL. > > I mean that it should return EDEADLK, not that the application > should actually deadlock. > > I realize SS2 PTHREAD_MUTEX_NORMAL _really_ has to deadlock the > thread, which is why we'd probably never want to map the default > mutex to this type. I'm just arguing that the default mutex > shouldn't allow a thread to lock it several times - it should > return EDEADLK on recursive lock attempts. When I think about it, it probably wouldn't create more problems, as it will only create problems if somebody is checking the return value (otherwise it will work as it already does). I still consider the decision to be in John Birrells camp, however, Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981129161418.W9226>