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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
