Date: Sun, 29 Nov 1998 21:00:47 +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: <19981129210047.Z9226@follo.net> In-Reply-To: <199811291714.MAA05445@pcnet1.pcnet.com>; from Daniel Eischen on Sun, Nov 29, 1998 at 12:14:11PM -0500 References: <199811291714.MAA05445@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 29, 1998 at 12:14:11PM -0500, Daniel Eischen wrote: > Eivind Eklund wrote: > > On Sun, Nov 29, 1998 at 09:31:18AM -0500, Daniel Eischen wrote: > > > 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. > > What does the P in Pthreads mean? Phenomenally stupid. Any standard that include locking and doesn't allow definition of recursive locks fall within this category. > Isn't SS2 based off an earlier rev (draft) of the POSIX spec? No - it is AFAIK a superset of the POSIX standard. It also require that if we detect the deadlock condition we should return EDEADLK - but we don't detect the case. Allowing a lock to be "re-aquired" by the same thread just falls out of the code. Another issue is that the standard isn't exactly internally consistent - it both require that a PTHREAD_MUTEX_NORMAL should deadlock if locked twice by the same thread, and that all deadlocks should return EDEADLK when detected. You _could_ construct this as 'PTHREAD_MUTEX_NORMAL should not detect deadlocks", but detecting deadlocks is the only way we can make it deadlock (and I consider dictating that it shouldn't detect is too much dictation of internal details, anyway). 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?19981129210047.Z9226>