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

[Mathieu Desnoyers]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 08/17/2011 03:41 AM, Mathieu Desnoyers wrote:
>> >      MB rcu_read_unlock = QSBR rcu_thread_offline + nesting count
>> >      MB rcu_read_lock   = QSBR rcu_thread_online + nesting count
>>
>> The statement above applies to all flavors of URCU. There is a clear
>> link between offline/online and nested read lock/unlock. We can see them
>> as the two sides of the same counter: one counts the reasons why a
>> thread is within a rcu critical section, while the other keeps track of
>> the reasons why a thread is not in a rcu critical section.
>
> Nicely put!
>
>> But MB/MEMBARRIER and SIGNAL schemes have all been derived from the same
>> 2-phase grace-period scheme, based on a lock/unlock nesting count, while
>> the QSBR implementation is a different beast that requires periodic
>> invocation of rcu_quiescent_state() by each application thread, which
>> makes it unsuitable for use of RCU within libraries.
>
> As an occasional contributor, I am glad what I wasn't saying total BS.  
> :)  Just one thing: rcu_quiescent_state is just an optimization of
>
>     rcu_thread_offline();
>     rcu_thread_online();

That's right.

>
> where the store of 0 to the gp_ctr is optimized away.  That was the  
> basis of my observation; but as far as the write-side is concerned, MB  
> and QSBR are basically the same thing.

Yep, which is why I even used the two-phases scheme in QSBR for 32-bit
machines. :-)

So I guess that in that sense, synchronize_rcu() of MB and QSBR could be
merged, is that what you are trying to get at ? (sorry for being slow on
the uptake) ;-)

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com