----- On Apr 5, 2021, at 1:43 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello all, > > I am using the QSBR flavor of URCU and I have a question: is it ok to call > rcu_register_thread more than once per thread? Yes, but you should unregister before registering again. > Similarly, is it ok to call > rcu_unregister_thread more than once per thread? Likewise: you should not have 2 unregistrations back-to-back without a registration in between. Note however that frequent registration/unregistration of a thread can lead to significant performance overhead and lock contention on the rcu_registry_lock, which is likely something you will want to avoid. > I am using a library that uses > a threadpool I have no control over. A thread from its threadpool invokes a > callback function of mine. Threads may be reused. I would like to call > rcu_register_thread at the beginning of my callback and rcu_unregister_thread > at the end. The thread in question may exit or may be reused at some later > point, I have no control over that. So I want to make sure that periodically > registering and unregistering the same thread is ok. Thanks for any > information. You may want to use the "urcu-bp" flavor instead. It has a slightly higher overhead than qsbr, but won't require as much fine-tuned integration with the threadpool runtime. But if you really want to do an efficient integration of urcu-qsbr with the threadpool without changing any of the threadpool, here are a few ideas though: - you could keep a "qsbr_registered" state in a TLS variable owned by your application, - lazily perform qsbr registration if needed, based on the "qsbr_registered" state, - put thread "offline" before returning control to the threadpool, - put thread "online" when entering your code again, - if the threadpool can call your application before the thread exits, then use that to unregister qsbr. Else, you could always use a dummy pthread key to have an application destructor called on thread exit, and unregister qsbr that way, Hoping this help! Best regards, Mathieu > > Jeff > _______________________________________________ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- 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
