[ltt-dev] [RFC] URCU concurrent data structure API
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Wed Aug 17 12:40:39 EDT 2011
Hi,
I'm currently trying to find a good way to present the cds_ data
structure APIs within URCU for data structures depending on RCU for
their synchronization. The main problem is that we have many flavors of
rcu_read_lock/unlock and call_rcu to deal with.
Various approaches are possible:
1) The current approach: require that the callers pass call_rcu as
parameter to data structure init functions, and require that the
callers hold rcu_read_lock across API invocation.
downsides: holds rcu read lock across busy-waiting loops (for longer
than actually needed). Passing call_rcu as parameter and putting
requirements on the lock held when calling the API complexify the API,
and makes it impossible to inline call_rcu invocations.
2) Require all callers to pass call_rcu *and* rcu_read_lock/unlock as
parameter to data structure init function.
downsides: both call_rcu and read lock/unlock become function calls
(slower). Complexify the API.
3) Don't require caller to pass anything rcu-related to data structure
init. Would require to compile one instance of each data structure
per RCU flavor shared object (like we're doing with call_rcu now).
Downside: we would need to ship per-rcu-flavor version of each data
structure.
Upside: simple API, no rcu read-side lock around busy-waiting loops,
ability to inline both call_rcu and rcu_read_lock/unlock within the
data structure handling code.
There are probably others, but I think it gives an idea of the main
scenarios I consider. I start to like (3) more and more, and I'm tempted
to move to it, but I would really like feedback on this API matter
before I take any decision.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list