* Paul E. McKenney ([email protected]) wrote:
> Hello!
>
> The following pair of patches permits a single executable to use
> multiple flavors of URCU without resorting to linker tricks. The
> approach is to map each flavor to a different namespace. The patches
> are as follows:
>
> 1. Provide pthread_atfork-friendly interfaces.
> 2. Map symbols to allow multiple flavors of URCU to be mixed.
>
> This does not yet centralize pthread_atfork() handling, nor does it
> yet map defer_rcu() and friends.
>
> Thoughts?
Hi Paul,
>
> Thanx, Paul
>
> a/urcu-call-rcu.c | 620
> -------------------------------------------------
> b/Makefile.am | 3
> b/README | 4
> b/tests/Makefile.am | 33 +-
> b/tests/rcutorture.h | 1
> b/tests/urcutorture.c | 13 -
> b/urcu-bp.c | 4
> b/urcu-bp.h | 8
> b/urcu-call-rcu-impl.h | 618
> ++++++++++++++++++++++++++++++++++++++++++++++++
I rather thought we could do something e.g. (for the rcu read lock):
* urcu header
- header
#ifdef RCU_MEMBARRIER
#define rcu_read_lock() rcu_read_lock_memb()
#endif
#ifdef LGPL_SOURCE
static inline rcu_read_lock_memb(void) {...}
#else
#define rcu_read_lock_mb() _rcu_read_lock_memb()
#endif
- implementation (c file)
#define RCU_MEMBARRIER
implements _rcu_read_lock_memb(void) and friends.
#include urcu-call-rcu-impl.h
* urcu-mb
(similar to the above, with _mb, RCU_MB)
* urcu-signal
(similar to the above, with _sig, RCU_SIGNAL)
* urcu-bp
(similarly, with _bp, RCU_BP)
* call_rcu
Looking into why we need to move urcu-call-rcu.c into
urcu-call-rcu-impl.h, I notice that it's because we need each RCU flavor
synchronize_rcu() to be used by each call_rcu.
I think all the -map files are missing from the patchset, which I think
is very important to understand how you plan to do the identifier
definitions. So maybe that my comment above is (or not) in line with
what you propose. We'll see with the -map header files.
Thanks,
Mathieu
> b/urcu-call-rcu.c | 29 ++
> b/urcu-qsbr.c | 36 +-
> b/urcu-qsbr.h | 18 -
> b/urcu.c | 5
> b/urcu.h | 20 +
> 14 files changed, 736 insertions(+), 676 deletions(-)
>
> _______________________________________________
> rp mailing list
> [email protected]
> http://svcs.cs.pdx.edu/mailman/listinfo/rp
--
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
