URCU feature request?

[Thobias Knudsen]

Yes but all read/write operations doesn't have the syntax of a function as
you used in the example here i.e. use(...). When it is a function you can
easily just change the implementation to check if it is called inside a
read section. Some reads and writes are usually done by this syntax (a = b)
and '=' cannot be overridden.

BTW just saying that what we're talking about now is not the original
topic, but if someone has an elegant solution to this that would be nice!

Thanks
Thobias

tir. 2. sep. 2025 kl. 23:34 skrev Ondřej Surý <ondrej at sury.org>:

> If I understand you correctly, you can do something like this:
>
> #undef rcu_read_lock
> #define rcu_read_lock() urcu_memb_read_lock(); {
>
> #undef rcu_read_unlock
> #define rcu_read_lock() } urcu_memb_read_unlock();
>
> (replace memb with your RCU variant of course)
>
> and make your code declare all the RCU protected pointers inside the RCU
> critical section, e.g.
>
> rcu_read_lock();
> my_pointer *foo = rcu_dereference(...);
>
> use(foo); /* valid */
>
> rcu_read_unlock();
>
>
> use(foo); /* invalid and caught by the compiler */
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at sury.org
>
> > On 2. 9. 2025, at 23:06, Thobias Knudsen via lttng-dev <
> lttng-dev at lists.lttng.org> wrote:
> >
> > Yes, that is what I'm worried about. For my case when using URCU that is
> my biggest concern, as the debug macro "library" I made checks everything
> else, if I haven't overlooked anything.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20250902/bf1d2955/attachment-0001.htm>