* Paolo Bonzini ([email protected]) 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
