How priority propagation works on read/write lock?

John Baldwin jhb at freebsd.org
Tue Jan 17 11:37:18 PST 2006


On Tuesday 17 January 2006 14:00, Daniel Eischen wrote:
> On Tue, 17 Jan 2006, John Baldwin wrote:
> > On Monday 16 January 2006 00:08, Kamal R. Prasad wrote:
> > > you mean, boosting the priority of a reader would be required to avoid
> > > priority inversion, but difficult to implement?
> > >
> > > regards
> > > -kamal
> > >
> > > On 1/14/06, John Baldwin <jhb at freebsd.org> wrote:
> > > > I think you just kind of punt and do a best effort.  Trying to manage
> > > > a list
> > > > of current read lock holders would be a bit PITA.
> >
> > Yes.  The actual boosting is rather simple, it's keeping track of who has
> > read locks that is ugly.
>
> Hmm, do you really care which or if all of the readers get their
> priority boosted?  Can't you just boost the priority of [any] one
> of the readers, and when he releases the lock and the reader lock
> count is still positive, boost the priority of another reader?
> Keep doing this until all the current readers have released the
> lock.  In a perfect world you'd like to boost all of the readers,
> but that's pretty hard without chaining together all the readers
> and allowing for nested locks.
>
> I'm assuming that this is only needed when a [higher priority]
> writer wants the read lock.

Yes, that is one possibility, and is a more complex method than what Solaris 
uses.  For now I'm just not doing any propogation for read locks in the hopes 
of having a simpler and _working_ implementation first that can then be 
experimented with further. :)

-- 
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 mailing list