How priority propagation works on read/write lock?
jhb at freebsd.org
Wed Jan 18 10:03:01 PST 2006
On Wednesday 18 January 2006 11:31, rookie wrote:
> 2006/1/18, Daniel Eischen <deischen at 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 at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-hackers