Hazard pointers - in C++26 vs Julia - concurrency/atomics e.g. for UInt128

I usually trust you since you’re the expert, but I saw:

8

So it only seems to be the “minimum” guaranteed limit. Maybe 16 IS guaranteed on x86, however, but I want that guarantee always(?). Do you think I always have it despite that, or maybe that don’t need it?

It should be 16-byte aligned (by default), but I’m not sure it is/guaranteed on all platforms:

One reasons is that most SSE2 instructions on X86 require the data to be 128 bit aligned. This design decision would have been made for performance reasons and to avoid overly complex (and hence slow and big) hardware.

FYI, existing on x86:
https://www.felixcloutier.com/x86/lddqu

LDDQU — Load Unaligned Integer 128 Bits

I do see in Julia.h (implying it might not always be):

// int128 is 16 bytes aligned on aarch64

In jl_compute_field_offsets (MAX_ALIGN is only 8):

It seems to be fixed in Zig, but not in Rust (any why not for a long time? Seems like a simple fix):

u128/i128 are not FFI-safe when they should be. That’s a bug. That’s why this issue exists and is still open. We also don’t claim that they are FFI safe, so it’s not a soundness bug.

@cmpxchg on x86_64 supports u128 integers. However @alignOf(u128) reports 8, and without align(16) on the u128, the code segfaults at runtime.

[Now fixed, but if not in Julia, then would also segfault, if using that instruction, so since it’s not likely actually is 16-byte aligned. I suppose that instruction IS used.]

Would you say all structs should be 16 bytes (no larger), 8, 4 etc. for concurrent programs (or use locking)?

Arrays are 64-byte aligned, if large, otherwise only 16-byte aligned, so larger 17, or 32byte has the possibility of straddling cache-line boundary.