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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
