aboutsummaryrefslogtreecommitdiff
path: root/vendor/spin/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/spin/README.md')
-rw-r--r--vendor/spin/README.md143
1 files changed, 0 insertions, 143 deletions
diff --git a/vendor/spin/README.md b/vendor/spin/README.md
deleted file mode 100644
index 7fd3780..0000000
--- a/vendor/spin/README.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# spin-rs
-
-[![Crates.io version](https://img.shields.io/crates/v/spin.svg)](https://crates.io/crates/spin)
-[![docs.rs](https://docs.rs/spin/badge.svg)](https://docs.rs/spin/)
-[![Build Status](https://travis-ci.org/mvdnes/spin-rs.svg)](https://travis-ci.org/mvdnes/spin-rs)
-
-Spin-based synchronization primitives.
-
-This crate provides [spin-based](https://en.wikipedia.org/wiki/Spinlock)
-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](https://matklad.github.io/2020/01/02/spinlocks-considered-harmful.html)
-by [@matklad](https://github.com/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`, `Once`, `Lazy` and `Barrier` equivalents
-- Support for `no_std` environments
-- [`lock_api`](https://crates.io/crates/lock_api) compatibility
-- Upgradeable `RwLock` guards
-- Guards can be sent and shared between threads
-- Guard leaking
-- Ticket locks
-- Different strategies for dealing with contention
-
-## Usage
-
-Include the following under the `[dependencies]` section in your `Cargo.toml` file.
-
-```toml
-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 mutex will become available again.
-
-```rust
-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;
- }
-
- thread.join().unwrap();
-
- 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`](https://crates.io/crates/lock_api)
-
-- `std` enables support for thread yielding instead of spinning.
-
-- `portable_atomic` enables usage of the `portable-atomic` crate
- to support platforms without native atomic operations (Cortex-M0, etc.).
- The `portable_atomic_unsafe_assume_single_core` cfg or `critical-section` feature
- of `portable-atomic` crate must also be set by the final binary crate.
-
- When using the cfg, this can be done by adapting the following snippet to the `.cargo/config` file:
- ```
- [target.<target>]
- rustflags = [ "--cfg", "portable_atomic_unsafe_assume_single_core" ]
- ```
- Note that this cfg is unsafe by nature, and enabling it for multicore systems is unsound.
-
- When using the `critical-section` feature, you need to implement the critical-section
- implementation that sound for your system by implementing an unsafe trait.
- See [the documentation for the `portable-atomic` crate](https://docs.rs/portable-atomic/latest/portable_atomic/#optional-cfg)
- for more information.
-
-## 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.
-
-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:
-
-```
-[dependencies]
-spin = { version = "x.y", default-features = false, features = [...] }
-```
-
-## Minimum Safe Rust Version (MSRV)
-
-This crate is guaranteed to compile on a Minimum Safe Rust Version (MSRV) of 1.38.0 and above.
-This version will not be changed without a minor version bump.
-
-## License
-
-`spin` is distributed under the MIT License, (See `LICENSE`).