Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Mon, Sep 09, 2013 at 01:29:08PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > On Mon, Sep 09, 2013 at 12:34:22PM -0400, Steven Rostedt wrote:
> [...]
> > > "rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"
> > 
> > You know, I am strongly tempted by "rcu_is_watching_you()", but I have
> > this feeling that it is too cute for its own good.  ;-)
> 
> Wow, I just got off the plane, and look at what happened to this thread
> ;-)

I had the same reaction when getting up this morning.  ;-)

> Referring to your earlier question Paul, what I meant by my earlier
> email on naming has been addressed by Steven: when exposing a new RCU
> API, even if it is just for in-kernel use, we should be really cautious
> not to tie it to implementation, but rather to concepts. Basically, my
> original thought is that we should be able to express the exact same
> concept in the kernel RCU implementation and in Userspace RCU. Here,
> binding the name on whether the CPU is watching RCU really makes no
> sense for urcu, since all the RCU flavors we currently have are watching
> threads, not CPUs.

More that that, userspace RCU doesn't have any energy management tie-ins.
It instead expects the application threads to invoke rcu_thread_offline()
when that thread goes idle and rcu_thread_offline() when the thread wakes
up again.  There is therefore less need for the application to query the
state because it was the application that set the state.

In contrast, within the Linux kernel, the RCU-watching state gets set
asynchronously with respect to in-kernel users of RCU.

Given the rest of the userspace RCU primitives, something like
rcu_thread_is_online() might make sense for the userspace RCU if some
application needs to know the state.  Or some other name that fits in
with rcu_thread_offline() and rcu_thread_online().  But such a name would
be problematic in the kernel due to CPU hotplug's use of those terms.

> Hence my proposal for "rcu_read_check()". It could be "rcu_is_active()"
> too, I don't really mind. It really minds: Is RCU actively watching the
> current execution context ? This can be translated to a runtime check
> too: is it safe to call rcu_read_lock() form this context ?

Although I do like rcu_is_active() better than rcu_read_check(), my
concern with rcu_is_active() is that it can easily be mistaken for a
global state rather than a per-CPU/thread/task/whatever state.

							Thanx, Paul