Date: Sun, 29 Nov 1998 17:27:58 -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: <199811292227.RAA02934@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
Eivind Eklund wrote: > On Sun, Nov 29, 1998 at 12:14:11PM -0500, Daniel Eischen wrote: > > 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. This falls into "undefined behaviour" which is allowed by POSIX mutexes. But one could interpret "undefined behaviour" as allowing for an implementation that cannot check mutex ownership. Since we can easily check mutex ownership with the cost of a couple extra instructions, we should do it. > 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). I'm glad you brought this up because I was kind of wondering why you implemented a deadlock as an infinite loop. Why not simply add the mutex to the waiting threads queue and restrict unlocks on PTHREAD_MUTEX_NORMAL to only the thread that owns the lock? This effectively deadlocks the thread because noone can ever unlock the mutex. Doing it this way, you don't have to "detect" a deadlock condition ;-) 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?199811292227.RAA02934>