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

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

----- 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