[lttng-dev] QSBR urcu read lock question

[lbj]

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.desnoyers at efficios.com> wrote:
> 
> ----- On Apr 13, 2021, at 11:19 PM, lttng-dev lttng-dev at 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