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. 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! 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 _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
