I have not investigated but as long as it does not trigger a data race warning using standard sanitizers, this PR looks great.

I have now tried running the existing threaded test with thread sanitizer, and it fails...

This gcc/clang only code (somewhat portable between architectures!) passes thread sanitizers (thanks to thread sanitizer understanding it, see https://github.com/google/sanitizers/wiki/ThreadSanitizerAtomicOperations):

 // 10.52 GB/s and thread sanitizer clean
const std::uint64_t tmp1 = __atomic_load_n((const std::uint64_t *)src, __ATOMIC_RELAXED);
const std::uint64_t tmp2 = __atomic_load_n((const std::uint64_t *)(src + 8), __ATOMIC_RELAXED);
std::memcpy(dst, &tmp1, sizeof(tmp1));
std::memcpy(dst + 8, &tmp2, sizeof(tmp2));

UPDATE: the above is portable if replaced with std::atomic_ref< std::uint64_t>

This simd code is portable between compilers, faster but does not pass thread sanitizer:

//12.09 GB/s, not thread sanitizer clean
const __m128i tmp = _mm_load_si128((const __m128i *)src);
_mm_storeu_si128((__m128i *)dst, tmp);

I think it is acceptable to get somewhat lower performance and get it sanitizer clean, but it however means one needs alternate code for gcc/clang vs msvc.

It would also be interesting to test some other tool than thread sanitizer, perhaps valgrind: https://valgrind.org/docs/manual/hg-manual.html
UPDATE: I tried valgrind --tool=helgrind and it did not give any warnings on any of the constructs, not even if I changed it to ordinary std::memcpy. It did however give warnings about std::barrier which I believe are false and did not go away even with the recommended macros under "Data Race Hunting" in https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html.

@pauldreik It is trivial to silence the sanitizers... see the function attributes...

https://clang.llvm.org/docs/ThreadSanitizer.html

But it won't work with other tools.

@pauldreik I think we could silence the sanitizers, that's what v8 does...

https://github.com/v8/v8/blob/611eac6d865e2957e9aa3bfd5d4bdb6f1b7bc660/src/heap/base/stack.cc#L56

I wrote #769 as a simpler alternative. It shies away from kernel specific code. I recommend not going there for now as it adds complexity that might not be needed on the short run.

(I am somewhat in a hurry of getting a new release out.)

I wrote #769 as a simpler alternative. It shies away from kernel specific code. I recommend not going there for now as it adds complexity that might not be needed on the short run.

(I am somewhat in a hurry of getting a new release out.)

closing this