Re: [lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ?

[Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>]

----- On Apr 19, 2021, at 5:41 AM, Duncan Sands baldrick@free.fr wrote:


> 
>> Quick question: should we use __atomic_load() or atomic_load_explicit() (C) and
>> (std::atomic<__typeof__(x)>)(x)).load() (C++) ?
> 
> If both are available, is there any advantage to using the C++ version when
> compiling C++?  As opposed to using the C11 one for both C and C++?

I recently noticed that using C11/C++11 atomic load explicit is not a good
fit for rcu_dereference, because we want the type to be a pointer, not an
_Atomic type. gcc appears to accept a looser typing, but clang has issues
trying to build that code.

So I plan to use __atomic(p, v, __ATOMIC_CONSUME) instead in both C and C++.

Also, I'll drop the cmm_smp_read_barrier_depends() when using __ATOMIC_CONSUME,
because AFAIU their memory ordering semantics are redundant for rcu_dereference.

Here is the resulting commit for review on gerrit:

https://review.lttng.org/c/userspace-rcu/+/5455 Fix: use __atomic_load() rather than atomic load explicit [NEW]

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev