Date: Sat, 15 Mar 2003 02:33:45 -0800 (PST) From: David Xu <davidxu@FreeBSD.org> To: David Schultz <das@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG, cvs-src@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG>, src-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libpthread/thread thr_rwlock.c Message-ID: <200303151033.h2FAXjEW073717@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "David Schultz" <das@FreeBSD.ORG> To: "David Xu" <davidxu@FreeBSD.ORG> Cc: "John Baldwin" <jhb@FreeBSD.ORG>; <cvs-all@FreeBSD.ORG>; <cvs-src@FreeBSD.ORG>; <src-committers@FreeBSD.ORG> Sent: Saturday, March 15, 2003 5:12 PM Subject: Re: cvs commit: src/lib/libpthread/thread thr_rwlock.c > Thus spake David Xu <davidxu@FreeBSD.org>: > > This design prevents a thread to get a reader lock recursively when > > there is a writter blocked on a rwlock. > > You're right in that the standard blesses the practice of a reader > recursing on a lock. Glancing briefly at the code, it looks like > we presently deadlock if a writer is waiting. However, the fix is > not so trivial. Writers *must* be given priority over readers > within a bounded amount of time or they will be starved. Consider > what happens when you have a neverending stream of readers. This can be done by keeping two lists of rwlocks the current thread owned, both for read lock and write lock. Everytime, a thread want to lock a rwlock, it will check one of these lists to see if it can recursively lock it. This will make rwlock slight heavy weight. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303151033.h2FAXjEW073717>