Re: URCU feature request?

[Thobias Knudsen via lttng-dev <lttng-dev@lists.lttng.org>]

[-- Attachment #1: Type: text/plain, Size: 3640 bytes --]

Figured out what rcu_read_ongoing does. It just returns true if it's called
within a read section and false otherwise. The problem for catching whether
reads are done outside read sections is that you can not make macros for
read and write operations. e.g. ptr->a = 4;.

tir. 2. sep. 2025 kl. 16:17 skrev Thobias Knudsen <thobknu@gmail.com>:

> > I suspect that what you are trying to achieve is validation that
> > calls to functions that require to be within a RCU read-side critical
> > section such as cds_lfht_lookup are indeed invoked from within a
> > critical section.
>
> Yes exactly, but not only for read sections. It could also be to validate
> that rcu_barrier isnt called within a callback function or that
> rcu_quiescent_state isnt called when thread is offline
>
> > We've added a "rcu_read_ongoing()" API for that purpose to liburcu
> > RCU flavors, but AFAIK it's not used for any kind of validation
> > within cds_lfht. This could indeed become a feature request that
> > would apply to all liburcu data structure APIs.
>
> I can't find any documentation on rcu_read_ongoing. Btw the documentation
> for urcu in general is scattered all around the repo it seems. It should
> have been all at one place imo. Should I make a feature request for it? I
> don't know how stuff works inside this repo though.
>
>
>
> man. 1. sep. 2025 kl. 17:09 skrev Mathieu Desnoyers <
> mathieu.desnoyers@efficios.com>:
>
>> On 2025-08-31 16:48, Thobias Knudsen wrote:
>> > BTW i've made a macro library which overrides the
>> > urcu and lfht functions. It checks that you call the functions in the
>> > correct order. This has been really useful for debugging and I think it
>> > would be useful to have it integrated into urcu to make the it more
>> user
>> > friendly. you could have it integrated with the macro DEBUG_RCU or make
>> > a new one, maybe DEBUG_FUNCTION_CALL_ORDER. The only thing it doesn't
>> > catch is if you continue to use data from cds_lfht_lookup() after
>> > rcu_read_unlock()
>>
>> I suspect that what you are trying to achieve is validation that
>> calls to functions that require to be within a RCU read-side critical
>> section such as cds_lfht_lookup are indeed invoked from within a
>> critical section.
>>
>> We've added a "rcu_read_ongoing()" API for that purpose to liburcu
>> RCU flavors, but AFAIK it's not used for any kind of validation
>> within cds_lfht. This could indeed become a feature request that
>> would apply to all liburcu data structure APIs.
>>
>> Thanks,
>>
>> Mathieu
>>
>> >
>> > søn. 31. aug. 2025 kl. 22:42 skrev Thobias Knudsen <thobknu@gmail.com
>> > <mailto:thobknu@gmail.com>>:
>> >
>> >     First question: why isn't Userspace RCU more popular?
>> >     Second question: Why isn't it possible to create issues in the urcu
>> >     repo? Im asking for a feature here:
>> >     Is it possible to make a function which checks if there are more
>> >     callbacks queued by call_rcu? I need that because there are some
>> >     callbacks which call call_rcu, and then calling rcu_barrier once
>> >     isn't enough and I therefore need a way to check if there are still
>> >     callbacks to wait on before terminating the program. No worries if
>> >     this is too much to ask for or if it isn't possible. This
>> >     functionality is only needed in termination because otherwise
>> >     isn't needed to call rcu_barrier multiple times (at least so far)
>> >
>> >     Best regards
>> >     Thobias
>> >
>> >
>>
>>
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> https://www.efficios.com
>>
>

[-- Attachment #2: Type: text/html, Size: 4768 bytes --]