Bug: 174788900

Clone this repo:
  1. 546844e Merge "Refresh Android.bp, cargo2android.json, TEST_MAPPING." by Joel Galenson · 6 weeks ago master
  2. 710e463 Refresh Android.bp, cargo2android.json, TEST_MAPPING. by Joel Galenson · 9 weeks ago
  3. 1ac96d3 Update TEST_MAPPING am: 64f4bfa2d2 am: 4a361056b1 am: 2636d9edbb by Joel Galenson · 5 months ago
  4. 2636d9e Update TEST_MAPPING am: 64f4bfa2d2 am: 4a361056b1 by Joel Galenson · 5 months ago
  5. 4a36105 Update TEST_MAPPING am: 64f4bfa2d2 by Joel Galenson · 5 months ago android-s-v2-preview-1 android-s-v2-beta-2 android-s-v2-preview-2


Crates.io version docs.rs Build Status

Spin-based synchronization primitives.

This crate provides spin-based versions of the primitives in std::sync. Because synchronization is done through spinning, the primitives are suitable for use in no_std environments.

Before deciding to use spin, we recommend reading this superb blog post by @matklad that discusses the pros and cons of spinlocks. If you have access to std, it's likely that the primitives in std::sync will serve you better except in very specific circumstances.


  • Mutex, RwLock, Once, Lazy and Barrier equivalents
  • Support for no_std environments
  • lock_api compatibility
  • Upgradeable RwLock guards
  • Guards can be sent and shared between threads
  • Guard leaking
  • Ticket locks
  • Different strategies for dealing with contention


Include the following under the [dependencies] section in your Cargo.toml file.

spin = "x.y"


When calling lock on a Mutex you will get a guard value that provides access to the data. When this guard is dropped, the mutex will become available again.

extern crate spin;
use std::{sync::Arc, thread};

fn main() {
    let counter = Arc::new(spin::Mutex::new(0));

    let thread = thread::spawn({
        let counter = counter.clone();
        move || {
            for _ in 0..100 {
                *counter.lock() += 1;

    for _ in 0..100 {
        *counter.lock() += 1;


    assert_eq!(*counter.lock(), 200);

Feature flags

The crate comes with a few feature flags that you may wish to use.

  • mutex enables the Mutex type.

  • spin_mutex enables the SpinMutex type.

  • ticket_mutex enables the TicketMutex type.

  • use_ticket_mutex switches to a ticket lock for the implementation of Mutex. This is recommended only on targets for which ordinary spinning locks perform very badly because it will change the implementation used by other crates that depend on spin.

  • rwlock enables the RwLock type.

  • once enables the Once type.

  • lazy enables the Lazy type.

  • barrier enables the Barrier type.

  • lock_api enables support for lock_api

  • std enables support for thread yielding instead of spinning.


It is often desirable to have a lock shared between threads. Wrapping the lock in an std::sync::Arc is route through which this might be achieved.

Locks provide zero-overhead access to their data when accessed through a mutable reference by using their get_mut methods.

The behaviour of these lock is similar to their namesakes in std::sync. they differ on the following:

  • Locks will not be poisoned in case of failure.
  • Threads will not yield to the OS scheduler when encounter a lock that cannot be accessed. Instead, they will ‘spin’ in a busy loop until the lock becomes available.

Many of the feature flags listed above are enabled by default. If you‘re writing a library, we recommend disabling those that you don’t use to avoid increasing compilation time for your crate's users. You can do this like so:

spin = { version = "x.y", default-features = false, features = [...] }


spin is distributed under the MIT License, (See LICENSE).