cosmopolitan/libc/sysv/calls/sys_futex_cp.S

#include "libc/sysv/macros.internal.h"
.scall sys_futex_cp,0x8a68539c62a038ca,2146,2563,globl,hidden
Make more code aarch64 friendly 2023-05-02 20:38:16 +00:00			`#include "libc/sysv/macros.internal.h"`
Make futexes 100x better on x86 MacOS Thanks to @autumnjolitz (in #876) the Cosmopolitan codebase is now acquainted with Apple's outstanding ulock system calls which offer something much closer to futexes than Grand Central Dispatch which wasn't quite as good, since its wait function can't be interrupted by signals (therefore necessitating a busy loop) and it also needs semaphore objects to be created and freed. Even though ulock is an internal Apple API, strictly speaking, the benefits of futexes are so great that it's worth the risk for now especially since we have the GCD implementation still as a quick escape hatch if it changes Here's why this change is important for x86 XNU users. Cosmo has a suboptimal polyfill when the operating system doesn't offer an API that let's us implement futexes properly. Sadly we had to use that on X86 XNU until now. The polyfill works using clock_nanosleep, to poll the futex in a busy loop with exponential backoff. On XNU x86 clock_nanosleep suffers from us not being able to use a fast clock gettime implementation, which had a compounding effect that's made the polyfill function even more poorly. On X86 XNU we also need to polyfill sched_yield() using select(), which made things even more troublesome. Now that we have futexes we don't have any busy loops anymore for both condition variables and thread joining so optimal performance is attained. To demonstrate, consider these benchmarks Before: $ ./lockscale_test.com -b consumed 38.8377 seconds real time and 0.087131 seconds cpu time After: $ ./lockscale_test.com -b consumed 0.007955 seconds real time and 0.011515 seconds cpu time Fixes #876 2023-10-03 21:47:20 +00:00			`.scall sys_futex_cp,0x8a68539c62a038ca,2146,2563,globl,hidden`