[ltt-dev] [RFC PATCH 0/7] priority-boost urcu

[Paolo Bonzini]

On 08/16/2011 12:58 AM, Lai Jiangshan wrote:
> These series patches implelent a priority-boost urcu
> based on pi-lock.
>
> Some other locks(especial rcu_gp_lock) should be also
> priority-aware, these patches did touch them and make
> the patchset simpler.

While really cool, I found this patchset overly complex.

What we should introduce is abstractions over futexes.  This is what I 
did to experimentally port URCU to QEMU---my secret goal since commit 
806f811 (use kernel style makefile output, 2010-03-01). :)  Our use of 
futexes is exceptionally similar to a Windows manual-reset event (yes, 
Windows: 
http://msdn.microsoft.com/en-us/library/system.threading.manualresetevent%28v=vs.80%29.aspx). 
  In QEMU I added the manual-reset event and use it in the 
implementation of RCU.

By introducing an abstraction for this, we can make the code a lot 
clearer and secondarily gain in portability.  For QEMU portability was 
actually my primary goal, but URCU might have different priorities. :)

PI futex support can also be implemented in the same framework.

By the way, it is my impression that MB (perhaps MEMBARRIER too?) is way 
way more similar to QSBR than to SIGNAL:

    MB rcu_read_unlock = QSBR rcu_thread_offline + nesting count
    MB rcu_read_lock   = QSBR rcu_thread_online + nesting count

Perhaps moving around code could make the code simpler?  Following the 
master/slave memory barrier functions is quite hard, and this is 
complicated by the KICK_READER_LOOPS that (if I understand correctly) 
makes little sense for non-SIGNAL models.

Paolo