proxima_primitives/sync/
blocking.rs

1//! `proxima_primitives::sync::blocking` — canonical tier-resolved BLOCKING mutex.
2//!
3//! Folded from the former `proxima-lock` crate (Workstream F, RISC-dedup:
4//! `proxima-lock` had zero workspace consumers — an adoption gap, not dead
5//! code). One `Mutex<T>` API, backend chosen by tier:
6//!
7//! - **std** (default): re-exports `parking_lot::{Mutex, MutexGuard}`
8//!   unchanged — a genuine passthrough, no behavior change for std
9//!   consumers.
10//! - **`no_std` + `blocking`**: `lock_api::Mutex` over a futex raw mutex
11//!   (`futex::RawFutexMutex`) backed by `atomic-wait` (Linux `futex`,
12//!   macOS `__ulock`, Windows `WaitOnAddress`).
13//!
14//! There is deliberately no spin fallback: a blocking lock needs an OS wait
15//! primitive, so `no_std` with neither `std` nor `blocking` exposes no
16//! `Mutex` at all rather than silently degrading to a spinlock.
17//!
18//! This module's `Mutex` PARKS a real OS thread — the lock-of-last-resort
19//! outside async contexts per the workspace hot-path discipline. It is
20//! deliberately namespaced away from [`crate::sync::Mutex`] (the crate-root
21//! ASYNC mutex, `futures::lock::Mutex`-backed, which yields the task
22//! instead of parking a thread) so the two never collide under one name.
23
24// `Condvar` rides with the std backend only: the futex tier has no wait-queue to
25// hang one on, so a no_std blocking worker waits on an async gate instead.
26#[cfg(feature = "std")]
27pub use parking_lot::{Condvar, Mutex, MutexGuard};
28
29#[cfg(all(not(feature = "std"), feature = "blocking"))]
30mod futex;
31#[cfg(all(not(feature = "std"), feature = "blocking"))]
32pub use futex::{Mutex, MutexGuard, RawFutexMutex};
proxima_primitives/sync/blocking.rs

proxima_primitives/sync/
blocking.rs
