Both waiter cases checked that acquire had not returned after a fixed
100 ms, without knowing the waiter thread had reached the call. Each
waiter now sets a started flag right before it calls acquire, and the
main thread waits for it with a 5 s deadline before the 100 ms wait.
The flag shows the thread got as far as the call, not that it is
blocked inside it; the 100 ms wait stays.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
The three guard exports had no test. The new one checks the Itanium C++
ABI guard protocol: a fresh guard is acquired once and reads initialized
after the release, an aborted acquisition leaves it uninitialized and
lets the next acquire succeed, two different guards nest on one thread,
and a second thread blocks until the holder releases (then sees the
object initialized) or takes over after an abort.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
