Date: Sun, 29 Nov 1998 19:10:34 -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: <199811300010.TAA12159@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
Eivind Eklund wrote: > 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 ;-) It also chews up process time that could be given to other threads. I'm implementing SCHED_FIFO and SCHED_RR and if a SCHED_FIFO thread ends up in this deadlock, then no other thread will run either. Hmm. If a SCHED_FIFO thread does deadlock, how should this affect the scheduling of other threads? 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?199811300010.TAA12159>