Use futex-based synchronization on Apple platforms #122408

joboet · 2024-03-12T20:36:51Z

Last week, Apple released macOS version 14.4, which introduced a public futex API called os_sync_wait_on_address (Apple has failed to include the documentation provided in the defining header os/os_sync_wait_on_address.h on its website). As the private API backing these functions has been around since macOS 10.12, our minimum supported version, it can be used as fallback without risking breakage in future versions.

This PR thus switches over Mutex to os_unfair_lock, which is movable and supports priority inheritance, and all other synchronization primitives (Condvar, RwLock, Once and thread parking) to the futex-based ones also used on Linux and Windows.

TODO: implement miri shims

rustbot · 2024-03-12T20:36:58Z

r? @m-ou-se

rustbot has assigned @m-ou-se.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

library/std/src/sys/pal/unix/futex.rs

BlackHoleFox · 2024-03-13T01:29:57Z

library/std/src/sys/pal/unix/futex.rs

+
+    // These syscalls appeared with macOS 10.12.
+    weak! {
+        pub fn __ulock_wait(u32, *mut c_void, u64, u32) -> c_int


Mind explaining more what the thought process of these going undetected is? Seems like a risky chance that might require a hot fix if the MAS or iOS app store scanners see through this.

In reality I think this won't be enough and we need to call ulock things via syscall directly instead. This means that the "fallback" Apple futex implementation is only going to be usable on macOS.

I know Electron apps on the MAS use direct syscalls to emulate private functions, so this is probably what Rust should do too on macOS with precedence:

#define SYS_ulock_wait 515 #define SYS_ulock_wake 516 #define SYS_ulock_wait2 544

For iOS, detect if the os_sync_ functions are available or fallback to the non-futex implementation :/ Calling a syscall directly is forbidden per the iOS headers so std can't do the same as macOS:

__WATCHOS_PROHIBITED __TVOS_PROHIBITED __OS_AVAILABILITY_MSG(ios,deprecated=10.0,"syscall(2) is unsupported; " "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().") __OS_AVAILABILITY_MSG(macosx,deprecated=10.12,"syscall(2) is unsupported; " "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().") int syscall(int, ...);

This is a "spirit of the law" kind of situation. Apple understandably wants App Store software to continue working in newer versions, so they prohibit private API use, as they want to be able to remove or change that API at will. By only using the private API as fallback and not linking it directly, we fulfil this wish. If we directly linked the private API instead, we'd get dynamic linker errors if they remove it, so we can't do that.

On the other hand, we break the "letter of the law" as we are using private API. In my opinion, this is totally fine and justified, but of course, this is only my interpretation. It would be great if someone from Apple could look over this, just so that we know that they are aware of this. My past attempt at reaching out to them for this has been unsuccessful.

Would you consider the solution of atomic-wait? They use libc++.

https://github.com/m-ou-se/atomic-wait/blob/main/src/macos.rs

But these only exist starting with macOS 11, which is way above our minimum of 10.12, so the ulock fallback would be needed regardless.

This sets precedent for using private APIs in the standard library (our current use of weak! is only used for symbols that are available in newer versions), which I think is a fairly big deal, and should perhaps be discussed more broadly (in a separate issue? (that could be FCP'ed?)).

Somewhat related is #114186. Tagging in particular @thomcc and @workingjubilee, as they seem to have been involved in this kind of stuff before?

At the very least, we should use the dlsym! macro explicitly here, to make it very clear that we're not weakly linking the symbol (which would be very visible in the binary), but actually loading it at runtime, and thereby evading the App Store's checks (dlsym itself seems to be allowed).

I believe this is sufficient such that we do not need to do raw syscalls (which I remember to have caused problems for Go in the past since as the ABI isn't stable (?)).

BlackHoleFox · 2024-03-13T01:30:23Z

library/std/src/sys/pal/unix/futex.rs

+                wait(UL_COMPARE_AND_WAIT | ULF_NO_ERRNO, addr, value, 0);
+            }
+        } else {
+            panic!("your system is below the minimum supported version of Rust");


These panics also get to be deleted if raw syscalls are used :)

If we do keep the panics, I'd go for an abort here instead, this is not recoverable in any way and avoiding the overhead from unwind landing pads would be nice.

bors · 2024-03-13T10:15:08Z

☔ The latest upstream changes (presumably #122423) made this pull request unmergeable. Please resolve the merge conflicts.

Implement the `os_unfair_lock` functions on macOS These are needed for rust-lang/rust#122408. See the documentation [here](https://developer.apple.com/documentation/os/synchronization?language=objc) and the implementation [here](https://github.com/apple-oss-distributions/libplatform/blob/a00a4cc36da2110578bcf3b8eeeeb93dcc7f4e11/src/os/lock.c#L645).

Implement the `os_unfair_lock` functions on macOS These are needed for rust-lang#122408. See the documentation [here](https://developer.apple.com/documentation/os/synchronization?language=objc) and the implementation [here](https://github.com/apple-oss-distributions/libplatform/blob/a00a4cc36da2110578bcf3b8eeeeb93dcc7f4e11/src/os/lock.c#L645).

madsmtm

In general, nice work, this will be a great perf improvement!

I know it is a draft, but once you're ready, it'd be nice to split the Mutex changes apart from the futex changes, if possible.

@rustbot label O-apple

madsmtm · 2024-09-26T12:21:40Z

library/std/src/sys/locks/condvar/mod.rs

+        target_os = "macos",
+        target_os = "ios",
+        target_os = "tvos",
+        target_os = "watchos",


Please use target_vendor = "apple", as that also includes visionOS. Also applies elsewhere.

madsmtm · 2024-09-26T12:55:08Z

library/std/src/sys/locks/mutex/apple.rs

+//!
+//! On Apple platforms, priority inheritance is the default for locks. To avoid
+//! having to use pthread's mutex, which needs some tricks to work correctly, we
+//! instead use `os_unfair_lock`, which is small, movable and supports priority-


movable

Could you provide some documentation for this claim? The comment on os_unfair_lock states:

In Swift, note that use of the & operator on an unfair lock can copy or move the lock memory, leading to misbehavior. Use an OSAllocatedUnfairLock to safely wrap access to the lock memory instead. If you use os_unfair_lock APIs directly, always make sure to store and use the lock in memory with a stable address.

Which seems to hint at the lock not being movable? Or am I misunderstanding?

madsmtm · 2024-09-26T13:01:50Z

library/std/src/sys/pal/unix/futex.rs

+/// See os/os_sync_wait_on_address.h (Apple has failed to upload the documentation
+/// to their website) for documentation of the public API and
+/// https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/bsd/sys/ulock.h#L69
+/// for the header file of the private API, along with its usage in libpthread
+/// https://github.com/apple-oss-distributions/libpthread/blob/d8c4e3c212553d3e0f5d76bb7d45a8acd61302dc/src/pthread_cond.c#L463


I'd also link the design/decision document:
https://github.com/apple-oss-distributions/libplatform/blob/libplatform-316.100.10/docs/expose-futex-style-api.md

library/std/src/sys/pal/unix/futex.rs

madsmtm · 2024-09-26T13:39:47Z

library/std/src/sys/pal/unix/futex.rs

+    if let Some(wake) = os_sync_wake_by_address_any.get() {
+        unsafe { wake(addr, size_of::<u32>(), OS_SYNC_WAKE_BY_ADDRESS_NONE) == 0 }
+    } else if let Some(wake) = __ulock_wake.get() {
+        // __ulock_wake can get interrupted, so retry until either waking up a
+        // waiter or failing because there are no waiters (ENOENT).
+        loop {
+            let r = unsafe { wake(UL_COMPARE_AND_WAIT | ULF_NO_ERRNO, addr, 0) };
+
+            if r >= 0 {
+                return true;
+            } else {
+                match -r {
+                    libc::ENOENT => return false,
+                    libc::EINTR => continue,
+                    err => panic!("__ulock_wake failed: {}", Error::from_raw_os_error(err)),
+                }
+            }
+        }


Hmm, are you sure this is correct? The implementation of os_sync_wake_by_address_any seems to just call __ulock_wake without a loop? So either we need to loop both places, or in none of them?

Same goes for futex_wake.

joboet added 4 commits March 9, 2024 12:46

std: allow weak in item position on Apple platforms

0398215

std: use futex for thread parking and Once on Apple platforms

82fa41a

std: use the futex-based Condvar and RwLock on Apple platforms

113f7e9

std: use os_unfair_lock for Mutex on Apple platforms

76b3461

joboet added the A-atomic Area: Atomics, barriers, and sync primitives label Mar 12, 2024

joboet marked this pull request as draft March 12, 2024 20:36

rustbot assigned m-ou-se Mar 12, 2024

rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 12, 2024

joboet mentioned this pull request Mar 12, 2024

Tracking issue for improving std::sync::{Mutex, RwLock, Condvar} #93740

Closed

63 tasks

BlackHoleFox suggested changes Mar 13, 2024

View reviewed changes

joboet added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 8, 2024

RalfJung mentioned this pull request Apr 18, 2024

Implement macOS dispatch semaphores rust-lang/miri#2589

Open

This was referenced Jul 9, 2024

macOS: add os_sync_wait_on_address and related definitions rust-lang/libc#3769

Merged

Implement the os_unfair_lock functions on macOS rust-lang/miri#3745

Merged

madsmtm suggested changes Sep 26, 2024

View reviewed changes

rustbot added O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) labels Sep 26, 2024

RalfJung mentioned this pull request Sep 29, 2024

Can we avoid the heap allocation in macOS Mutex/Condvar? #131005

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use futex-based synchronization on Apple platforms #122408

Use futex-based synchronization on Apple platforms #122408

joboet commented Mar 12, 2024

rustbot commented Mar 12, 2024

BlackHoleFox Mar 13, 2024

joboet Mar 13, 2024

Berrysoft Sep 21, 2024

joboet Sep 22, 2024

madsmtm Sep 26, 2024 •

edited

Loading

BlackHoleFox Mar 13, 2024

madsmtm Sep 26, 2024 •

edited

Loading

bors commented Mar 13, 2024

madsmtm left a comment

madsmtm Sep 26, 2024

madsmtm Sep 26, 2024

madsmtm Sep 26, 2024

madsmtm Sep 26, 2024

Use futex-based synchronization on Apple platforms #122408

Are you sure you want to change the base?

Use futex-based synchronization on Apple platforms #122408

Conversation

joboet commented Mar 12, 2024

rustbot commented Mar 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

madsmtm Sep 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

madsmtm Sep 26, 2024 • edited Loading

Choose a reason for hiding this comment

bors commented Mar 13, 2024

madsmtm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

madsmtm Sep 26, 2024 •

edited

Loading

madsmtm Sep 26, 2024 •

edited

Loading