* Paul E. McKenney ([email protected]) wrote: > Provides call_rcu_before_fork() and call_rcu_after_fork_parent() to > go with the existing call_rcu_after_fork_child(). > > Signed-off-by: Paul E. McKenney <[email protected]> > --- > README | 4 ++++ > urcu-call-rcu.c | 29 ++++++++++++++++++++++++++++- > 2 files changed, 32 insertions(+), 1 deletions(-) > > diff --git a/README b/README > index f7f0dec..56e98d7 100644 > --- a/README > +++ b/README > @@ -204,3 +204,7 @@ Interaction with fork() > liburcu-bp, which is designed to handle fork() by calling > rcu_bp_before_fork, rcu_bp_after_fork_parent and > rcu_bp_after_fork_child. > + > + Applications that use call_rcu() are required to invoke > + call_rcu_after_fork_child() from the child process after a > + successful fork() system call that is not followed by exec(). > diff --git a/urcu-call-rcu.c b/urcu-call-rcu.c > index bb56dbb..665f20c 100644 > --- a/urcu-call-rcu.c > +++ b/urcu-call-rcu.c > @@ -566,13 +566,40 @@ void free_all_cpu_call_rcu_data(void) > } > > /* > + * Acquire the call_rcu_mutex in order to ensure that the child sees > + * all of the call_rcu() data structures in a consistent state. > + * Suitable for pthread_atfork() and friends. > + */ > +void call_rcu_before_fork(void) > +{ > + call_rcu_lock(&call_rcu_mutex); > +} > + > +/* > + * Clean up call_rcu data structures in the parent of a successful fork() > + * that is not followed by exec() in the child. Suitable for > + * pthread_atfork() and friends. > + */ > +void call_rcu_after_fork_parent(void) > +{ > + call_rcu_unlock(&call_rcu_mutex); > +} > + > +/* > * Clean up call_rcu data structures in the child of a successful fork() > - * that is not followed by exec(). > + * that is not followed by exec(). Suitable for pthread_atfork() and > + * friends. > */ > void call_rcu_after_fork_child(void) > { > struct call_rcu_data *crdp; > > + /* Re-initialize the mutex. */ > + if (pthread_mutex_init(&call_rcu_mutex, NULL) != 0) { > + perror("pthread_mutex_init"); > + exit(-1);
Hi Paul, I tried to turn UST from a scheme where "unlock" is executed in both the parent and child processes (which works fine) to a scheme where we use "pthread_mutex_init" in the child as you do here. For some reason, the fork stress-test seems to hang when I do that. So I would be tempted to turn all the "pthread_mutex_init" we do after fork in children processes into a mutex. I'd like to understand better what is causing this trouble though, but until then I would be tempted to turn these "re-init" into "unlock". Thoughts ? Mathieu > + } > + > /* > * Allocate a new default call_rcu_data structure in order > * to get a working call_rcu thread to go with it. > -- > 1.7.3.2 > > > _______________________________________________ > 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
