Mathieu, Thanks so much for your wealth if information and timely responses, they are greatly appreciated. Final question: is there any harm in explicitly calling rcu_thread_online/rcu_thread_offline from within my call_rcu callback function? From what you described it sounds like it would be redundant, but presumably would be harmless. Correct? Thanks again. Jeff
Sent from my iPhone > On Apr 15, 2021, at 9:04 AM, Mathieu Desnoyers > <mathieu.desnoy...@efficios.com> wrote: > > ----- 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
