[ltt-dev] [rp] [PATCH RFC urcu 0/2] allow multiple URCU flavors in one executable

[Paul E. McKenney]

On Mon, Mar 28, 2011 at 07:21:16PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck at linux.vnet.ibm.com) 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

I get a similar effect with the *map.h files, see attached.
(Yes, I forgot to do "git add"...  Sigh!)

> * 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.

Yep!

> 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.

They are currently a bunch of #defines, see attached.

							Thanx, Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urcu-map.h
Type: text/x-chdr
Size: 4708 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110328/e0b0ff15/attachment-0009.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urcu-bp-map.h
Type: text/x-chdr
Size: 2414 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110328/e0b0ff15/attachment-0010.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urcu-qsbr-map.h
Type: text/x-chdr
Size: 2576 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110328/e0b0ff15/attachment-0011.h>