----- Original Message ----- > From: "Florian Lohoff" <[email protected]> > To: [email protected] > Sent: Friday, January 31, 2014 3:16:32 PM > Subject: [lttng-dev] URCU accessing rcu_head->func > > > Hi, > > i am having multiple timer which can issue a call_rcu on an object using > an rcu_head. > > It can happen than an object is already on the call_rcu list > for destruction and another timer fires. > > So i am doing something like this. > > if (!rs->rcuhead.func) { > call_rcu(&rs->rcuhead, free_obj); > } > > I have a feeling in my gut that this didnt blow up > just by accident and i am doing something utterly stupid. > > I am in the read side critical section so my structure > cant appear under my feet but the above can be racy at > best.
I guess you meant "disappear" here ? > > What would be the best way to achieve something like: > > "queue for call_rcu if not already queued" > > Another flag with an atomic inc or something? Indeed, the scheme you describe above seems to be racy, since there could be two or more read-side critical sections accessing the same object concurrently, and doing two call_rcu() enqueuing the same object (same linked list node) twice into the call_rcu lists will simply corrupt those lists. Let me first rephrase your intent here just to make sure I understand: you use RCU read-side to provide existence guarantee on the "rs" object, and you want to enqueue the object rcuhead with call_rcu() for deletion (free_obj) after a grace period has elapsed. Assuming you care about keeping this code path wait-free or lock-free (at least), using uatomic_xchg() would allow you to set an atomic flag and know, from the returned value, whether you "own" the object reclaim or not. You can then decide whether or not call_rcu() needs to be called based on the value read by uatomic_xchg(). You could do something similar with mutexes, but then you would lose the wait-freedom characteristic of this code path, which I am guessing is one key reason why you use RCU read-side lock and call_rcu() in the first place. Does it make sense ? Thanks, Mathieu > > Flo > -- > Florian Lohoff [email protected] > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
