[libcxx-commits] [PATCH] D68480: Implementation of C++20's P1135R6 for libcxx

[Valery Mironov via Phabricator via libcxx-commits]

MBkkt added inline comments.


================
Comment at: libcxx/src/atomic.cpp:38
+    static constexpr timespec __timeout = { 2, 0 };
+    syscall(SYS_futex, __ptr, FUTEX_WAIT_PRIVATE, __val, &__timeout, 0, 0);
+}
----------------
__simt__ wrote:
> MBkkt wrote:
> > Why do you use timed wait here?
> > It's strange, and also different with macos(ulock) behavior 
> Because it would be incorrect otherwise.
> 
> There's an infinitesimal but not zero probability that the serial number being waited on can roll over, incremented by precisely the right value, and then you might think it didn't change when it did.
> 
> There are a lot of weird discussions we could have from here. Does this negate Futex? I don't think it should. Is it even worth worrying about (like, the computer might be hit by a neutron flying in from space much more often than this)? I think it's cheap to mitigate.
> 
> There's a judgement-call here about how long to wait. It's arbitrary.
> 
> We wouldn't need to do this if Linux supported 64-bit Futex. Partly because we would rarely use serial numbers like this, and also partly because 64-bit numbers don't roll over inside of the useful life span of computer hardware.
First of thanks for answer.

But if I understand correctly it's only about not atomic<int> behavior (any atomic which use waiter pool)
So for atomic<int> it's not needed (also why unsigned int not used in wait without waiter pool?)

Another thought, for ulock behavior should be same?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68480/new/

https://reviews.llvm.org/D68480