What is the right way to use Atomics.notify return value?

[empijei]

Currently Atomics.wait waits on a value and returns without waiting if the value has changed since it was loaded.

This means that the right way to deterministically use wait is looping:

for (;;) {
  Atomics.load(arr, 0)
  // Check if condition to exit has occourred, if so exit loop
  Atomics.wait(arr, 0, val);
  // Potentially check the return value for "not-equal"
}

On the other end of the communication a script must invoke Atomics.notify, which returns the amount of workers that were notified by this call.

I couldn't come up with the correct way to use this value without races:

• If wait is executed in a loop, a change in the array might cause the looping end to return before a wait, making notify always return 0 even if the other thread got the message.
• If wait and notify are not executed in a loop, there is a clear race between them, and I wonder what is the intended use case for this (a notify could get lost if it wins the race)
• If notify is executed in a loop, it can only keep notifying in a tight loop until it wakes a thread, which doesn't seem like a good thing to do.

What is the intended use-case for the value returned by Atomics.notify?

Thanks in advance for the explanations.

[lars-t-hansen]

In general, wait and notify are not directly useful as a an event signaling mechanism at the user program level; they must normally be wrapped in a little bit of protocol or they will be unreliable (lost wakeups). One obvious example of such a protocol is in the implementation of a lock, see eg here.

The return value of notify can be used to implement such a protocol, if you control enough details of the protocol and checking the number of woken threads is a good fit; I expect the distinction between 0 woken and 1 woken is particularly interesting.

That said, notify was given a return value because (a) the futex spec, that the wait/notify mechanism was originally copied from, had one, and (b) it seemed like a good idea to make available information that only the wait/notify layer had available to it, and there was no reason to keep it secret. Looking through my various experiments, I've not yet found any code that uses the return value from notify - most protocols prefer to use a little bit of state on the side, with some kind of sequence lock to ensure that things happen in the correct order.

[empijei]

Thanks for replying.

I expect the distinction between 0 woken and 1 woken is particularly interesting

how can you use the 0 correctly? Maybe on the other end someone picked up the change and returned, so they were "woken" but not via notify.

I am trying to implement synchronization primitives on top of Atomics and I implemented

• Mutex
• WaitGroup
• Barrier
• Once
• Semaphore

And not once I could use the return value from notify without incurring in a race.

I understand that FUTEX_WAKE returns the amount of woken threads, but was there any good use of it? Looking at all the source code I have available to me (including all github) I found no relevant one.
Almost every example I found of C/CPP code that wraps the futex syscall hides away the returned value. The only exception is to check if the return value is greater than a sentinel value and in that case abort because the program got in a corrupted state.

Even in the linux tests the way to test that value is to use an usleep call and hope that the scheduler doesn't make the test flaky.

the wait/notify layer had available to it, and there was no reason to keep it secret

I am inclined to think that this value is misleading, and hiding it would make the Atomics.notify API easier to use and less error-prone.

If this is not doable, I'd argue that documenting this value with some warning could be valuable and prevent some coders future headaches.