Date: Mon, 17 Mar 2003 14:14:45 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: David Xu <davidxu@FreeBSD.org> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_rwlock.c Message-ID: <XFMail.20030317141445.jhb@FreeBSD.org> In-Reply-To: <200303150347.h2F3lLjK069888@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-Mar-2003 David Xu wrote:
> This design prevents a thread to get a reader lock recursively when
> there is a writter blocked on a rwlock.
You didn't say that that was your reason earlier, and you didn't update
the comment you rendered obsolete. To me this means you don't fully
grasp the reasons behind the earlier code. If you don't keep track of
holders of read locks and allow recursive read locks, then yes, you can
get into a deadlock. This is why the in-kernel sx locks don't use this
same algorithm at the moment. However, a more complete log message or
a follow up should explain the reasons you are doing things and should
not leave rotted comments around.
> ----- Original Message -----
> From: "John Baldwin" <jhb@FreeBSD.org>
> To: "John Baldwin" <jhb@FreeBSD.org>
> Cc: <src-committers@FreeBSD.org>; <cvs-src@FreeBSD.org>; <cvs-all@FreeBSD.org>; "David Xu"
> <davidxu@FreeBSD.org>
> Sent: Saturday, March 15, 2003 3:31 AM
> Subject: RE: cvs commit: src/lib/libpthread/thread thr_rwlock.c
>
>
>>
>> On 14-Mar-2003 John Baldwin wrote:
>> >
>> > On 14-Mar-2003 David Xu wrote:
>> >> davidxu 2003/03/13 17:02:47 PST
>> >>
>> >> FreeBSD src repository
>> >>
>> >> Modified files:
>> >> lib/libpthread/thread thr_rwlock.c
>> >> Log:
>> >> Fix a bug in rwlock. When a rwlock was locked by reader threads, a
>> >> writter thread can block reader threads to get read lock.
>> >
>> > That's not a bug. That is a very common way of implementing reader
>> > writer locks. The idea is that if a writer is waiting for the lock
>> > you make later read requests wait for the lock so that they don't
>> > starve the writer. This is how Solaris rw locks work for example.
>> > The in-kernel sx locks don't currently work that way, but that
>> > may change at some point in the future. For more discussion on why
>> > Solaris chose this route, go find a copy of Solaris Internals.
>> >
>> > You probably should revert this and find out if this was an
>> > intentional design decision rather than a "bug".
>>
>> Looking at the diff a bit more:
>>
>> @@ -157,7 +157,7 @@
>> return(ret);
>>
>> /* give writers priority over readers */
>> - while (prwlock->blocked_writers || prwlock->state < 0) {
>> + while (prwlock->state < 0) {
>> ret = pthread_cond_wait(&prwlock->read_signal, &prwlock->lock);
>>
>> if (ret != 0) {
>>
>> The comment above the while loop seems to indicate that this was
>> indeed a design choice. As a result of this change the comment no
>> longer applies. Please revert.
>>
>> --
>>
>> John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
>> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.20030317141445.jhb>