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.
I do wonder if it is worth while.
it would require an internediated structure that would be simultaneously
linked into
a number of structures..
it would be linked into a list of "read locks held by this thread,
and it would be linked into a list of "threads currently reading on this
read lock"
it would however be a rathe small item, and I can imagine that a cache
of a thousand or so of these
would probably do enough for the system.
Something like:
struct rwlock_nexsus {
SLIST_ENTRY( rwlock_nexus) by_thread;
struct thread *owner;
SLIST_ENTRY (rwlock_nexus) by_lock;
struct rwlock *locked;
}
on a x86 this would be 16 bytes long.. on an amd64, 32 bytes
in a page of 4k (x86) you get 256 of them.
that's quite a few considerring that we have only 4 processers or so
running code at a time
and you probably shouldn't be unscheduled while holding one..
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
