Re: [lttng-dev] QSBR urcu read lock question

[lbj via lttng-dev <lttng-dev@lists.lttng.org>]

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.desnoyers@efficios.com> wrote:
> 
> ----- On Apr 15, 2021, at 8:41 AM, lbj lbj137@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.desnoyers@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