[libcxx-commits] [libcxx] [libc++] Allows any types of size 4 and 8 to use native platform ulock_wait (PR #161086)

[via libcxx-commits]

================
@@ -0,0 +1,58 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: no-threads
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+
----------------
huixie90 wrote:

I think I finally got to the bottom (sort of) of the failure.

First of all, it is timeout not due to the lost wake up. It is purely because the test is extremely slow on these runners. The tests have 1 notify thread, 8 waiting threads, and the main thread. It is likely overloading the runner machine. I also seen that the trunk (non back deployment) version also failed once. I have put some debug print on the notifying thread. In the CI runner, the notifying thread is slowly making progress, but eventually did not make to the final iterations before the timeout killer killed the whole process. See the log [here](https://productionresultssa9.blob.core.windows.net/actions-results/0724c5fe-2bcb-4c81-aea1-951a7e8b2415/workflow-job-run-32db7f1a-8de7-5c1e-8491-d6b1d60defa2/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-12-07T11%3A36%3A43Z&sig=5oqLyoXn14pKRyQzadMqnWgu59FiRAfTqLf%2Fnj1AyuA%3D&ske=2025-12-07T22%3A28%3A28Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-12-07T10%3A28%3A28Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2025-12-07T11%3A26%3A38Z&sv=2025-11-05)

I then tried to figure out why the tests are super slow on the runner (`>1800s`) , whereas it only took `1s` on our own machines. I noticed I have a `std::this_thread::yield` in the notifier's loop. I remember that macOS would put the `yield` thread on the lowest priority on the scheduler. If the machine is overloaded with other running jobs, our notifier thread may take long time to resume again. So as an experiment, I removed the `yield` from the test, and run it again
```
while (waiter_ready.load() < num_waiters) {
-    std::this_thread::yield();
}
```
We can see that without `yield`, the test only took `14s` to finish on these runners. See log [here](https://productionresultssa1.blob.core.windows.net/actions-results/d4079433-951c-4faa-9bd8-1ef8e4ba780f/workflow-job-run-dd2c709d-afee-5ed2-a447-b5ce7a6e9a20/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-12-07T11%3A53%3A40Z&sig=5%2BN20ZdQeQjWnbX3SHT5ZAbe4z9xzI9Rkd9EcV373%2B0%3D&ske=2025-12-07T22%3A35%3A30Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-12-07T10%3A35%3A30Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2025-12-07T11%3A43%3A35Z&sv=2025-11-05) (btw, i made the test always fail in order to see the logs)

So my final fix is that we don't need to disable the back deployment for this test. We can simply remove the `yield` from the test and the CI is green now


On the separate note, I am fully convinced that we should remove `yield` everywhere. I noticed in the log the slowest test was
```
733.55s: apple-libc++-system.cfg.in :: std/thread/thread.semaphore/lost_wakeup.pass.cpp
```

In this test, we have a `std::barrier` and `std::barrier`'s wait function uses `__libcpp_timed_backoff_policy`, which has a `__libcpp_thread_yield` in it. We have not removed it yet though it was discussed in https://github.com/llvm/llvm-project/issues/123855 
I think it is time to get rid of it now



https://github.com/llvm/llvm-project/pull/161086