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) [email protected] 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 > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
