[lttng-dev] liburcu qsbr call_rcu quiescence

[Mathieu Desnoyers]

Hi David,

Please create a new discussion thread when posting a question next
time. It will help others following the lttng-dev archives. You will
find the answer to your question below,

----- On Nov 20, 2015, at 5:33 PM, David Boles (dboles) dboles at micron.com wrote:

> I’m using the liburcu system (qsbr flavor) with its list structures as well as a
> variant of a bonsai tree.
> 
> In my unit testing code I have a race between the rcu callback invocation thread
> (currently just the default one) invoking a callback it was given and the main
> thread tearing down data that callback depends on.
> 
> In looking at the call_rcu_thread() function, it looks like that thread sleeps
> for no more than ~10ms. However, even if I guarantee 20ms elapses between the
> last time call_rcu() is called and my teardown, I am still seeing the callback
> thread processing "old" call_rcu() requests. This appears correlated with the
> callback thread having thousands of free's to process.
> 
> In my real application I happened to have set things up so that everything
> associated with rcu-managed allocation is freed with call_rcu() so I'm not
> seeing a problem there (so far). However, I suspect the same issue could crop
> up with abnormal exit paths.
> 
> How do I reliably determine that all rcu callbacks registered prior to some
> point in time have been processed?

There's an API for that! :-)

See rcu_barrier(). It has been introduced in liburcu 0.8.

Ref:
https://github.com/urcu/userspace-rcu/blob/master/doc/rcu-api.md

"void rcu_barrier(void);

Wait for all call_rcu() work initiated prior to rcu_barrier() by any thread
on the system to have completed before rcu_barrier() returns. rcu_barrier()
should never be called from a call_rcu() thread. This function can be used,
for instance, to ensure that all memory reclaim involving a shared object
has completed before allowing dlclose() of this shared object to complete."

Thanks,

Mathieu

> 
> Thanks,
> 
> David Boles
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com