How priority propagation works on read/write lock?

[Julian Elischer]

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.
>
>  
>
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..