Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.11, 11.4
Description
The intended purpose of the inline function MY_RELAX_CPU() is to ensure that the current thread does not hog the memory bus in a spin loop. The generic implementation is doing exactly the opposite of that intention. Quoting the code for 10.6; in 10.5 an ARMv8 instruction isb had been added in MDEV-24630:
static inline void MY_RELAX_CPU(void) |
{
|
#if 0 /* ... */
|
#elif defined __GNUC__ && (defined __arm__ || defined __aarch64__)
|
/* Mainly, prevent the compiler from optimizing away delay loops */ |
__asm__ __volatile__ ("":::"memory"); |
#else
|
int32 var, oldval = 0;
|
my_atomic_cas32_strong_explicit(&var, &oldval, 1, MY_MEMORY_ORDER_RELAXED,
|
MY_MEMORY_ORDER_RELAXED);
|
#endif |
The GNUC fallback above is processor agnostic; therefore we had better enable it for all processors, to benefit LoongArch and IBM System Z (s390x) for example. For RISC-V, there is __builtin_riscv_pause() that is a valid encoding in all ISA versions, including ones that do not implement the Zihintpause extension.
I also experimented with std::atomic_thread_fence()}, but it fails to prevent loops from optimized away.
Attachments
Issue Links
- relates to
-
MDEV-8684 UT_RELAX_CPU isn't at all relaxing
-
- Closed
-
- links to
Please go ahead.