Date: Wed, 18 Jan 2006 12:34:17 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org, rookie@gufi.org Cc: Daniel Eischen <deischen@freebsd.org> Subject: Re: How priority propagation works on read/write lock? Message-ID: <200601181234.19349.jhb@freebsd.org> In-Reply-To: <3bbf2fe10601180831r69dbf1f9j@mail.gmail.com> References: <3bbf2fe10601180715k25297666y@mail.gmail.com> <Pine.GSO.4.43.0601181100511.18649-100000@sea.ntplx.net> <3bbf2fe10601180831r69dbf1f9j@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 18 January 2006 11:31, rookie wrote: > 2006/1/18, Daniel Eischen <deischen@freebsd.org>: > > I assume we already know how to propagate priority for mutexes, so > > once you know how to propagate for RWlocks, it all just works. > > As I can see, propagate priority for mutex needs a little modify to > turnstiles code, that's not a great deal. > > > Yes, once you choose a thread to propagate, you have to keep > > propagating through whatever it is blocked on or until you > > reach a point where the propagated priority is <= the priority > > of the next thread in the heirarchy. I never questioned that > > part of it, just the need to do it for all threads owning the > > RW lock at the same time. > > Maybe it's not "strictly" necessary but please consider that "blocking > hierarchies" are never too long and a total priority propagation would be > quicker (you however need to propagate to every owner in the end so doing > it at the same time could craft a bottleneck if the hierarchy is too long, > but it's a rare case and in the opposite way you need to rule 'what thread > needs to be update' every time a blocking thread is unblocked). One thing you need to think about is allowing for the fact that a thread might hold multiple read locks of the same lock (i.e., recursion) and it can hold read locks of more than one read lock. Your current use of a field in struct thread to link together the list of read owners for a lock won't work in the case of a thread holding a read lock of two different rw locks. This is why I think it is too hard to keep track of all the readers. Otherwise you have to provide storage somewhere else for the list of threads and it needs to not use malloc or rwlocks will be intolerably slow. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601181234.19349.jhb>