[ltt-dev] [RFC] URCU concurrent data structure API

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Wed Aug 17 12:40:39 EDT 2011


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

   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.



Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.

More information about the lttng-dev mailing list