----- On Apr 15, 2021, at 8:41 AM, lbj lbj...@yahoo.com wrote: > Hi Mathieu, > When I say “reclamation thread” I do mean the thread launched by call_rcu that > is typically responsible for memory deallocations. Is is possible/recommended > to register for rcu and then take an rcu-reader lock in such a thread? That is > my main question. > > As for reader locks being no-ops in QSBR, I read that but dont quite > understand > it. Something must be preventing memory reclamation of rcu protected elements > when I take that lock.
Note that a RCU read-side "lock" is really just a marker about the beginning/end of a transaction which delays grace periods. We use the name "lock" to match the kernel RCU APIs, but it should not be considered as doing any kind of mutual exclusion. > > My specific situation is: I have a QSBR rcu protected “policy” object (just a > regular old C++ object that periodically gets refreshed and must be atomically > updated because worker cores are reading it while spinning, and they cant slow > down). When a new policy is received we invoke call_rcu on the old policy. > call_rcu will eventually launch a thread in which the old policy’s resources > are reclaimed. In this thread I would like to iterate through another, > separate > structure, which is also QSBR rcu protected (a urcu hashtable). To do so > safely, presumably I must use an rcu readlock. I just want to make sure such a > scenario is reasonable and at very least not contra-indicated. Thanks! If you look at urcu-call-rcu-impl.h, you will notice that call_rcu_thread() indeed registers itself as a reader thread. So the call-rcu callbacks can indeed take a RCU read-side lock, but for QSBR the story does not end there, because due to the nature of QSBR, the read-side lock is indeed a no-op, and it relies instead on all registered QSBR reader threads to periodically invoke urcu_qsbr_quiescent_state() to report that they are in a quiescent state, or invoke urcu_qsbr_thread_offline() if they expect to be in a quiescent state for a long period of time (e.g. blocking), followed by urcu_qsbr_thread_online(). And indeed, the call_rcu_thread puts itself in "offline" mode while awaiting for grace periods (this is implicitly done within the qsbr synchronize_rcu() implementation) and when sleeping. So yes, you should be able to have a RCU read-side from within a call-rcu worker thread, and it's OK to assume you can do a RCU traversal with the QSBR urcu flavor from a call-rcu worker thread as well. Thanks, Mathieu > > Jeff > > > > Sent from my iPhone > >> On Apr 15, 2021, at 8:20 AM, Mathieu Desnoyers >> <mathieu.desnoy...@efficios.com> >> wrote: >> >> ----- On Apr 13, 2021, at 11:19 PM, lttng-dev lttng-dev@lists.lttng.org >> wrote: >> >>> Hello all, >>> >>> I have two different entities that are both protected by QSBR rcu: a policy >>> and >>> a hashtable. In the reclamation thread for the policy I would like to take a >>> read lock so that I can safely iterate through the hashtable. I dont see >>> anything wrong with this, but I just wanted to make sure it was ok since >>> taking >>> an rcu read lock in an rcu reclamation thread seems like it may be a bit >>> suspect. Thanks for any insights, let me know if clarification is needed! >> >> When you say "the reclamation thread for the policy", do you refer to a >> call-rcu >> worker thread ? >> >> Also, you are aware that RCU read-side lock/unlock are effectively no-ops for >> QSBR rcu, right ? >> >> Thanks, >> >> Mathieu >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. > > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
