Date: Sun, 29 Nov 1998 09:31:18 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, eivind@yes.no 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: <199811291431.JAA22106@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> 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? 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 ;-). > > Both POSIX and Single UNIX Spec 2 allow this. SS2 allows that > > you can map PTHREAD_MUTEX_DEFAULT to any one of the other > > mutex types - it should be mapped to PTHREAD_MUTEX_ERRORCHECK. > > Ideally it probably should. > > > 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. Dan Eischen eischen@vigrid.com 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?199811291431.JAA22106>