Hi Mathieu, Thanks for your reply. I somehow missed this email of yours, and saw it today while I was clearing my inbox.
I appreciate your prompt response. Thanks, Siddharth On Mon, May 2, 2016 at 1:53 PM, Mathieu Desnoyers < [email protected]> wrote: > > ----- On Apr 29, 2016, at 3:10 PM, siddharth teotia < > [email protected]> wrote: > > The mail was accidentally sent. Here is more info: > > My question really is that when writing a user space application that > leverages RCU, how do I ensure that I am using the proper > flavor/implementation of RCU ? I don't think so I can go ahead with > non-preemptive RCU. And the user space paper does not really tell or > distinguish clearly as to which of the following -- QSBR, MB, BP, signal > can be used for preemptive environments and do not restrict the reader to > not block or not sleep ? > > Hi, > > You appear to be confused between concepts that apply to the Linux kernel > RCU implementation (preemptible vs non-preemptive RCU read-side critical > sections) and those that apply to the Userspace RCU library (flavors: mb, > signal, > qsbr, bp). > > All Userspace RCU flavors read-side critical sections are preemptible, > because we cannot disable preemption when running in user-space. > Therefore, you may block or sleep within liburcu read-side critical > sections. However, if you do so, you need to be careful not to place > calls to synchronize_rcu() within code that have a transitive blocking > dependency on a RCU read-side, which would cause a deadlock. > > For instance, using the same mutex within a read-side critical section, > _and_ holding this mutex while calling synchronize_rcu() in another thread, > can trigger a deadlock. > > The main differences between liburcu flavors is detailed here: > https://lwn.net/Articles/573424/#URCU%20Flavors > > Thanks, > > Mathieu > > > Thanks, > Siddharth > > On Fri, Apr 29, 2016 at 12:07 PM, siddharth teotia < > [email protected]> wrote: > >> Hi Guys, >> >> I recently started exploring RCU to build a lock free hash table. I have >> read quite a bit of literature from LWN on RCU, its usage, API etc. I have >> the following question for which I have had mixed answers online: >> >> Does the user space implementation of RCU liburcu take care of preemptive >> v/s non-preemptive flavors of RCU. From what I understand RCU can be >> broadly divided into: >> >> 1. Classic RCU - High Performance but suitable for non-preemptive >> environments. >> 2. Preemptible RCU - Permits the reader to block on a resource or the >> read side critical sections to be preempted. But still does not allow any >> kind of sleep(). Moreover there seems to be some sort of limitation on the >> nature of blocking that can happen within RCU read side critical section. >> 3. Sleepable RCU - Seems to me an augmentation of preemptible RCU. >> >> The paper that describes the user space implementation of RCU suggests 4 >> different flavors -- QSBR, Memory Barrier based, Bullet Proof, and Signal >> based. >> >> I don't think so in my application I can afford to not have the readers >> block or even sleep. If the reader wants to take some orthogonal lock/latch >> on an entirely different resource, it might end waiting for it. >> >> And because >> >> >> > > > -- > *Best Regards,* > *SIDDHARTH TEOTIA* > *2008C6PS540G* > *BITS PILANI- GOA CAMPUS* > *+91 87911 75932 <%2B91%2087911%2075932>* > > _______________________________________________ > lttng-dev mailing list > [email protected] > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com > -- *Best Regards,* *SIDDHARTH TEOTIA* *2008C6PS540G* *BITS PILANI- GOA CAMPUS* *+91 87911 75932*
_______________________________________________ lttng-dev mailing list [email protected] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
