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? Thanks, David Boles _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
