[lttng-dev] QSBR urcu read lock question

[lbj]

Thank you again for all your help Mathieu!

Sent from my iPhone

> On Apr 15, 2021, at 3:26 PM, Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> 
> ----- On Apr 15, 2021, at 2:11 PM, lbj lbj137 at yahoo.com wrote:
> 
>> Thanks Mathieu. Is it safe to assume that if call_rcu is called twice then the
>> callbacks are executed in the order that call_rcu was invoked? I think there is
>> a queue and only one thread that QSBR uses to handle callbacks, i just wanted
>> to make sure that the queue was a guaranteed fifo.
> 
> It may very well depend on your configuration. For instance, if an application
> invokes create_all_cpu_call_rcu_data(), it will create per-cpu worker threads
> on each possible CPU. In that configuration, a given thread invoking call_rcu()
> twice (back to back) may be migrated from one CPU to another in between, hence
> different call-rcu worker threads will be responsible for executing the callbacks,
> and they can be executed in any order.
> 
> So even though by careful analysis of your specific application configuration you
> may presume that the callbacks will be executed in the same order they were invoked,
> this is not guaranteed by the API, so I would not recommend relying on FIFO order
> assumptions.
> 
> And given that the call_rcu API does not guarantee FIFO order, we could eventually
> decide to change the order of callback execution from FIFO to LIFO if it leads to
> performance improvements due to better cache locality.
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com