[lttng-dev] RCU Question

[siddharthteotia@gmail.com (siddharth teotia)]

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 ?

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160429/7a67a790/attachment.html>