parking_lot
A faster, smaller drop-in replacement for Rust's standard library Mutex, RwLock, Condvar, and Once.
Repository Health
Technical Analysis
parking_lot provides Mutex, RwLock, Condvar, and Once implementations that are smaller, faster, and more flexible than the ones in Rust’s standard library, plus a ReentrantMutex for recursive locking. It’s built on a low-level “parking lot” API (in the companion parking_lot_core crate) — the same design pattern used by WebKit’s JavaScriptCore — that manages queues of parked (blocked) threads efficiently, letting the higher-level lock types stay as small as a single byte or word instead of allocating OS-specific primitives on the heap.
Benchmarks in the README show parking_lot’s Mutex roughly 1.5x faster than std::sync::Mutex when uncontended and up to 5x faster under contention, with RwLock seeing gains up to 50x in some multi-reader scenarios. The crate is one of the most-depended-upon in the Rust ecosystem (nearly a billion total downloads), used transitively by countless other crates that need efficient synchronization primitives — including the type-safe generic lock API it publishes separately as lock_api, which other crates use to build their own custom lock types on the same fast core.
What You Get
- Mutex, RwLock, Condvar, and Once types that are drop-in faster replacements for std::sync equivalents
- A ReentrantMutex type supporting recursive locking, which std::sync does not provide
- A low-level parking_lot_core API for building custom synchronization primitives on the same efficient thread-parking mechanism
- lock_api, a type-safe generic lock API that other crates use to implement their own Mutex/RwLock-like types
- Optional features: fair mutexes, hardware lock elision on supported x86 processors, deadlock detection, and serde support
Common Use Cases
- Replacing std::sync::Mutex/RwLock in performance-sensitive multi-threaded Rust code to cut contention overhead
- Building custom lock types on top of lock_api’s generic RawMutex/RawRwLock traits
- Using ReentrantMutex where a thread may need to re-acquire a lock it already holds
- Debugging deadlocks in production via the optional deadlock-detection feature that periodically scans for cycles
Under The Hood
Architecture — The crate’s public types (mutex.rs 385 lines, rwlock.rs 659 lines, condvar.rs 1,273 lines, once.rs 498 lines) are thin wrappers around raw primitive implementations (raw_mutex.rs, raw_rwlock.rs 1,158 lines) that in turn build on the separately-published parking_lot_core crate (in core/src/), which implements the actual parking-lot algorithm: a global hash table of wait queues (word_lock.rs, parking_lot.rs) that lets threads park/unpark without each lock needing its own OS-level primitive. lock_api sits alongside as a generic, type-safe trait layer (RawMutex, RawRwLock) that both this crate and third-party crates build concrete lock types on top of.
Tech Stack — Pure Rust with minimal dependencies (lock_api, parking_lot_core, optional serde for serialization support), platform-specific thread-parking backends under core/src/thread_parker/ for Unix, Windows, and wasm. Uses cfg-gated optional features (hardware-lock-elision, deadlock_detection, arc_lock, send_guard) rather than always-on complexity.
Code Quality — Test coverage leans on doctests and dedicated regression tests for specific historical bugs (tests/issue_203.rs, tests/issue_392.rs), plus CI that runs under Miri (ci/miri.sh) for undefined-behavior detection — an important signal of rigor for unsafe, low-level concurrency code. Activity has slowed to ‘moderate’ per GitHub metrics, consistent with a mature, largely feature-complete crate rather than one being actively rewritten.
API Design — The types are intentionally near-identical in shape to std::sync’s Mutex/RwLock, so migration is usually a matter of swapping the import; extras like raw locking without a RAII guard and atomic write-to-read downgrading are additive rather than disruptive to that familiar API. The one real learning-curve cost is understanding the optional feature flags (fairness, elision, deadlock detection) well enough to pick the right trade-offs, since each changes performance/behavior characteristics non-trivially.
Used by 17 apps in this directory
ParadeDB
Analytics · Databases · Search
Born out of Y Combinator's S2023 batch, ParadeDB is a Postgres extension that delivers Elasticsearch-quality BM25 search and real-time analytics without a separate search cluster to manage.
PostgresML
AI Development · Databases
Run ML training and LLM inference natively inside PostgreSQL with GPU acceleration — no data movement required.
RustDesk
Networking
Open-source, self-hosted remote desktop built in Rust — your data, your infrastructure, no third-party cloud.
Spacedrive
Collaboration · File Storage
One file manager for all your devices and clouds — powered by a Virtual Distributed File System built in Rust.
Stalwart
Collaboration
All-in-one secure mail and collaboration server covering IMAP, JMAP, SMTP, CalDAV, CardDAV, and WebDAV in a single memory-safe Rust binary.
Temps
Analytics · Devops · Monitoring
A self-hosted Rust PaaS that replaces Vercel, Sentry, PostHog, Pingdom, Resend, and E2B with one binary — plus 440+ CLI operations agents like Claude Code can drive directly.
Volga
Data Engineering
A Rust-based real-time data processing engine for AI/ML feature computation, built on Apache DataFusion and Arrow — positioned as an alternative to Flink, Spark, Chronon, and OpenMLDB with unified streaming, batch, and request-time execution.
WrenAI
AI Agents · Analytics · Data Engineering
Open-source GenBI engine that lets AI agents turn natural-language questions into governed SQL, charts, and shareable dashboards across 20+ data sources — no vendor lock-in, no black-box prompts.