On Wednesday, 20 July 2022 13:52:21 PDT zwhconst via Std-Discussion wrote:
> Question 1:
> Does the "eligible to be unblocked" property/attribute have "time"
> constraint?
> Being "eligible to be unblocked by a particular atomic notifying
> operation" is a property of an atomic waiting operation.

There's no time constraint. You can block for a century, even after the
notify(). In fact, a perfectly valid albeit useless implementation would be
for notify() to do nothing and wait() to block forever, just like any
contended mutex locking could simply block forever too.

> Question 3: What does an atomic notifying operation unblocks?
> - X: it unblocks the whole atomic waiting operation. Once the (selected)
> atomic waiting operation is unblocked, it is always unblocked.
> - Y: it unblocks only one round of blocking of the atomic waiting
> operation. If the atomic waiting operation wakes up and blocks again, it
> needs another atomic notifying operation to unblock.
> Which one is correct, X or Y?

Y: if it's notified and woken up, it needs to sleep again if it wasn't meant to
be woken up.

That's why implementing anything more complex than a non-recursive mutex is
impossible to do properly with atomic_wait. To avoid too many spurious wake
ups or thundering herd problems, you need the ability to selectively wake up a
subset of all waiters (often just one in specific). A mutex can just
notify_one() and any waiter that was woken up is as good as any other waiter;
for a read-write lock, however, if you are doing an exclusive unlock and
there's a pending exclusive waiter, you want to wake up one of the exclusive
waiters, but not any of the shared waiters.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering