mirrors/cosmopolitan
1
0
Fork 0
mirror of https://github.com/jart/cosmopolitan.git synced 2025-01-31 03:27:39 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
cosmopolitan/libc/intrin/ulock.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

55 lines
3.1 KiB
C
Raw Normal View History

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
/*-*- mode:c;indent-tabs-mode:nil;c-basic-offset:2;tab-width:8;coding:utf-8 -*-│
│ vi: set et ft=c ts=2 sts=2 sw=2 fenc=utf-8 :vi │
╞══════════════════════════════════════════════════════════════════════════════╡
│ Copyright 2023 Justine Alexandra Roberts Tunney │
│ │
│ Permission to use, copy, modify, and/or distribute this software for │
│ any purpose with or without fee is hereby granted, provided that the │
│ above copyright notice and this permission notice appear in all copies. │
│ │
│ THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL │
│ WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED │
│ WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE │
│ AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL │
│ DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR │
│ PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER │
│ TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR │
│ PERFORMANCE OF THIS SOFTWARE. │
╚─────────────────────────────────────────────────────────────────────────────*/
#include "libc/intrin/ulock.h"
#include "libc/assert.h"
#include "libc/calls/calls.h"
#include "libc/calls/syscall_support-sysv.internal.h"
#include "libc/dce.h"
#include "libc/intrin/describeflags.h"
#include "libc/intrin/strace.h"
// XNU futexes
// https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/bsd/sys/ulock.h.auto.html
// https://opensource.apple.com/source/xnu/xnu-3789.41.3/bsd/kern/sys_ulock.c.auto.html
int sys_ulock_wait(uint32_t operation, void *addr, uint64_t value,
uint32_t timeout_micros) asm("sys_futex_cp");
Improve threading and i/o routines - On Windows connect() can now be interrupted by a signal; connect() w/ O_NONBLOCK will now raise EINPROGRESS; and connect() with SO_SNDTIMEO will raise ETIMEDOUT after the interval has elapsed. - We now get the AcceptEx(), ConnectEx(), and TransmitFile() functions from the WIN32 API the officially blessed way, using WSAIoctl(). - Do nothing on Windows when fsync() is called on a directory handle. This was raising EACCES earlier becaues GENERIC_WRITE is required on the handle. It's possible to FlushFileBuffers() a directory handle if it's opened with write access but MSDN doesn't document what it does. If you have any idea, please let us know! - Prefer manual reset event objects for read() and write() on Windows. - Do some code cleanup on our dlmalloc customizations. - Fix errno type error in Windows blocking routines. - Make the futex polyfill simpler and faster.
2023-10-13 01:53:17 +00:00
// returns number of other waiters, or -1 w/ errno
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
int ulock_wait(uint32_t operation, void *addr, uint64_t value,
uint32_t timeout_micros) {
int rc;
operation |= ULF_WAIT_CANCEL_POINT;
Make ulock stracing less noisy
2023-10-03 22:18:56 +00:00
LOCKTRACE("ulock_wait(%#x, %p, %lx, %u) → ...", operation, addr, value,
timeout_micros);
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
rc = sys_ulock_wait(operation, addr, value, timeout_micros);
Introduce posix_spawn_file_actions_addchdir_np()
2023-10-12 03:26:28 +00:00
LOCKTRACE("ulock_wait(%#x, %p, %lx, %u) → %d% m", operation, addr, value,
timeout_micros, rc);
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
return rc;
}
// returns -errno
int ulock_wake(uint32_t operation, void *addr, uint64_t wake_value) {
int rc;
rc = __syscall3i(operation, (long)addr, wake_value, 0x2000000 | 516);
Introduce posix_spawn_file_actions_addchdir_np()
2023-10-12 03:26:28 +00:00
LOCKTRACE("ulock_wake(%#x, %p, %lx) → %s", operation, addr, wake_value,
DescribeErrno(rc));
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
return rc;
}
Reference in a new issue Copy permalink