Date: Mon, 30 Nov 1998 00:37:38 +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: <19981130003738.E9226@follo.net> In-Reply-To: <199811292227.RAA02934@pcnet1.pcnet.com>; from Daniel Eischen on Sun, Nov 29, 1998 at 05:27:58PM -0500 References: <199811292227.RAA02934@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 29, 1998 at 05:27:58PM -0500, Daniel Eischen wrote: > 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 ;-) Simpler, more obvious code with less chance of me or some later change in the threads library screwing it up. Elegant code is code that reads straight forward and just does what it is supposed to ;-) Besides, I believe this lower the cost for non-deadlock cases, which don't need to check more than they already do (but I didn't check the code for this right now; I don't clearly remember if this was part of my evaluation. Main reason was obviousness.) 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?19981130003738.E9226>