Allow using spin from DnsResolver

Test: m
Bug: 155855709
Change-Id: I008805658e9ad081201c25f5ac7c8d0db0fffe73
2 files changed
tree: 5421f883b7d1390c46a93ccc361071b9e8b13be4
  1. .cargo_vcs_info.json
  2. .github/
  3. .gitignore
  4. .travis.yml
  5. Android.bp
  6. CHANGELOG.md
  7. Cargo.toml
  8. Cargo.toml.orig
  9. LICENSE
  10. METADATA
  11. MODULE_LICENSE_MIT
  12. OWNERS
  13. README.md
  14. TEST_MAPPING
  15. examples/
  16. patches/
  17. script/
  18. src/
README.md

spin-rs

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.

Features

  • Mutex, RwLock and Once equivalents
  • Support for no_std environments
  • lock_api compatibility
  • Upgradeable RwLock guards
  • Guards can be sent and shared between threads
  • Guard leaking
  • std feature to enable yield to the OS scheduler in busy loops
  • Mutex can become a ticket lock

Usage

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

spin = "x.y"

Example

When calling lock on a Mutex you will get a guard value that provides access to the data. When this guard is dropped, the lock will be unlocked.

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..10 {
                *counter.lock() += 1;
            }
        }
    });

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

    thread.join().unwrap();

    assert_eq!(*counter.lock(), 20);
}

Feature flags

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

  • lock_api enabled support for lock_api

  • ticket_mutex uses a ticket lock for the implementation of Mutex

  • std enables support for thread yielding instead of spinning

Remarks

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.

License

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