[lttng-dev] RCU Question

siddharth teotia siddharthteotia at gmail.com
Sat Jun 4 00:21:59 UTC 2016


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 <
mathieu.desnoyers at efficios.com> wrote:

>
> ----- On Apr 29, 2016, at 3:10 PM, siddharth teotia <
> siddharthteotia at gmail.com> 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 <
> siddharthteotia at gmail.com> 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
> lttng-dev at lists.lttng.org
> 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160603/f66b58ec/attachment-0001.html>


More information about the lttng-dev mailing list