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

Palli · January 16, 2024, 3:52pm

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

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):

github.com

JuliaLang/julia/blob/b058146cafec8405aa07f9647642fd485ea3b5d7/src/datatype.c#L694


      
                      // and contains non-pointer fields of non-zero sizes.
                      haspadding = 1;
                  }
                  if (!zeroinit)
                      zeroinit = ((jl_datatype_t*)fld)->zeroinit;
                  npointers += fld_npointers;
              }
          }
          else {
              fsz = sizeof(void*);
              if (fsz > MAX_ALIGN)
                  fsz = MAX_ALIGN;
              al = fsz;
              desc[i].isptr = 1;
              zeroinit = 1;
              npointers++;
              if (!jl_pointer_egal(fld)) {
                  // this somewhat poorly named flag says whether some of the bits can be non-unique
                  haspadding = 1;
              }
          }

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

github.com/rust-lang/rust

i128 / u128 are not compatible with C's definition.

opened 01:42AM - 19 Sep 18 UTC

emilio

A-LLVM A-ffi T-compiler C-bug A-abi

While fixing various bindgen bugs related to `long double`, `int128`, (https://g…ithub.com/rust-lang-nursery/rust-bindgen/issues/1370, etc). I realized that the following Rust program, in my x86_64 Linux machine: ```rust #[repr(C)] struct Foo { f: u128, } fn main() { println!("Align: {}", ::std::mem::align_of::<Foo>()); } ``` Prints `8`. While the following C program: ```c #include <stdio.h> struct foo { unsigned __int128 t; }; int main() { printf("Align: %ld\n", _Alignof(struct foo)); } ``` Prints `16` on the same system. This is pretty unexpected, and means that i128 / u128 are not really usable for FFI / alignment purposes.

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.

github.com/ziglang/zig

make the alignment of >= 128 bit integer types 16 bytes to prevent failure to properly align u128 when using 16-bit cmpchxg

opened 06:46AM - 01 Aug 19 UTC

closed 01:13AM - 21 Aug 19 UTC

andrewrk

enhancement stage1 arch-x86_64

`@cmpxchg` on x86_64 supports u128 integers. However `@alignOf(u128)` reports 8,… and without `align(16)` on the `u128`, the code segfaults at runtime. This alignment is reported by LLVM as the "ABI alignment". Is this alignment incorrect? Is the atomic alignment requirement higher? Investigation is needed. Here's the test case: ```zig test "128-bit cmpxchg" { if (builtin.arch != .x86_64) { return error.SkipZigTest; } var x: u128 = 1234; // segfault at runtime can be fixed by adding align(16) here if (@cmpxchgWeak(u128, &x, 99, 5678, .SeqCst, .SeqCst)) |x1| { expect(x1 == 1234); } else { @panic("cmpxchg should have failed"); } while (@cmpxchgWeak(u128, &x, 1234, 5678, .SeqCst, .SeqCst)) |x1| { expect(x1 == 1234); } expect(x == 5678); expect(@cmpxchgStrong(u128, &x, 5678, 42, .SeqCst, .SeqCst) == null); expect(x == 42); } ```

@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.