Currently it isn't possible to have a global spin lock because global vars must be statically initialized. Unfortunately the only solution at the moment is to make both fields public so they can be initialized by hand (for this exact reason value is public in anUnsafeCell).

I'd like a wrapper for them, trivial using AtomicBool. Just exposing cpu_relax might be enough for spin-compatible implementations.

Multiple issues in the RwLock implementation.

The first (and the worst) one is here:

impl<'rwlock, T: ?Sized> Drop for RwLockWriteGuard<'rwlock, T> {
    fn drop(&mut self) {
        self.lock.store(0, Ordering::Relaxed);
    }
}

Use of Ordering::Relaxed is incorrect. The compiler is free to reorder a write behind this, which could lead to two mutable refs being used at the same time (UB). It should be Ordering::Release instead (maybe this was just a typo?). Other parts of this code use the needlessly strict SeqCst ordering, but that's not a soundness issue.

The second that I've found is a bug in the try_read function:

    pub fn try_read(&self) -> Option<RwLockReadGuard<T>>
    {
        let old = (!USIZE_MSB) & self.lock.load(Ordering::Relaxed);
		// readers variable could be incremented here
        let new = old + 1;
        if self.lock.compare_and_swap(old,
                                      new,
                                      Ordering::SeqCst) == old
        {
            Some(RwLockReadGuard {
                lock: &self.lock,
                data: unsafe { & *self.data.get() },
            })
        } else {
            None
        }
    }

The problem is that a different thread could increment the readers count on the indicated line, making the value that the CAS checks for incorrect - it might fail even if there are no writers at all. For example:

    let lock = Arc::new(spin::RwLock::new(0));

    {
        let lock = lock.clone();
        thread::spawn(move || {
            loop {
                lock.try_read().unwrap();
            }
        });
    }

    thread::spawn(move || {
        loop {
            // Increment and decrement readers count in a loop
            lock.read();
        }
    }).join();

This code panics for me, even though it there are no writers so try_read should always succeed.

To be frank, I think it would be better to simply rewrite this whole implementation. The original blog that this was implemented from uses the writers bit to allow for recursive write locking (which this crate doesn't) - I see no reason not to just use some sentinel value like -1 to indicate a writer is holding the lock.

This use case may be a little obscure, so "we don't support that" is a perfectly reasonable response. But, just in case:

On a POSIX system, I have some shared data which I need to access from multiple threads but also from a signal handler. This is generally not possible:

1. Mutex is based on pthread_mutex, which is not async-signal-safe.
2. Even if it were, if a thread holding the lock gets a signal delivered, then the handler's attempt to acquire the lock that the thread already holds is forbidden, and will cause deadlocks or panics.

I can work around 2) by simply blocking the signals whenever I hold the lock.

I was hoping to use this crate to work around 1), but the std feature means that I cannot count on this crate's spinlocks not to use std::thread::yield_now, which (oddly) is not async-signal-safe.

Even if I don't enable the std feature myself, crates used by multiple dependents are compiled with the union of the features requested by all those dependents. So if my crate happens to be used with someone else who wants spin with the std feature, then I get libc::sched_yield calls in my signal handlers.

My concerns would be addressed if there were a separate Mutex type that was guaranteed never to use sched_yield or any other non-async-signal-safe system calls, regardless of which features were enabled.

Thanks for your consideration!

In the call_once() function documentation, there is a typo at the very end of the 3rd paragraph:

/// When this function returns, it is guaranteed that some initialization
/// has run and completed (it may not be the closure specified). The
/// returned pointer points to the return value of when of those
/// initialization closures.

I think the last sentence should be something like this, but I'm not 100% sure.

The returned pointer points to the value returned by the initialization closure parameter, even on future invocations.

See e. g. https://github.com/mvdnes/spin-rs/actions/runs/3987644011/jobs/6837740845.

 stderr:
error: Undefined Behavior: not granting access to tag <3224> because that would remove [SharedReadOnly for <3170>] which is strongly protected because it is an argument of call 814
   --> /home/runner/work/spin-rs/spin-rs/src/rwlock.rs:536:32
    |
536 |                 data: unsafe { &mut *inner.data.get() },
    |                                ^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <3224> because that would remove [SharedReadOnly for <3170>] which is strongly protected because it is an argument of call 814
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <3224> was created by a SharedReadWrite retag at offsets [0x8..0xc]
   --> /home/runner/work/spin-rs/spin-rs/src/rwlock.rs:536:38
    |
536 |                 data: unsafe { &mut *inner.data.get() },
    |                                      ^^^^^^^^^^^^^^^^
help: <3170> is this argument
   --> /home/runner/work/spin-rs/spin-rs/src/rwlock.rs:516:29
    |
516 |     fn try_upgrade_internal(self, strong: bool) -> Result<RwLockWriteGuard<'rwlock, T, R>, Self> {
    |                             ^^^^
    = note: BACKTRACE (of the first span):
    = note: inside `spin::rwlock::RwLockUpgradableGuard::<'_, i32>::try_upgrade_internal` at /home/runner/work/spin-rs/spin-rs/src/rwlock.rs:536:32: 536:54
note: inside `spin::rwlock::RwLockUpgradableGuard::<'_, i32>::try_upgrade`
   --> /home/runner/work/spin-rs/spin-rs/src/rwlock.rs:556:9
    |
556 |         self.try_upgrade_internal(true)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `main::_doctest_main_src_rwlock_rs_545_0`
   --> src/rwlock.rs:549:7
    |
7   | match upgradeable.try_upgrade() {
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `main`
   --> src/rwlock.rs:553:3
    |
11  | } _doctest_main_src_rwlock_rs_545_0() }
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to previous error

(There are more errors, but that should be enough to get the basic idea.)

The failure seems to be related to stacked borrows, but checking violations of stacked borrows with MIRI is still considered experimental at this moment.

One way to fix this would be to add the -Zmiri-disable-stacked-borrows flag for invokations of MIRI, but according to its documentation that is unsound:

• -Zmiri-disable-stacked-borrows disables checking the experimental
  [Stacked Borrows] aliasing rules. This can make Miri run faster, but it also
  means no aliasing violations will be detected. Using this flag is unsound
  (but the affected soundness rules are experimental).

This structure behaves a lot like a normal Mutex. There are some differences:

• It may be used outside the runtime.
  • A normal mutex will fail when used without the runtime, this will just lock
  • When the runtime is present, it will call the deschedule function when appropriate
• No lock poisoning. When a fail occurs when the lock is held, no guarantees are made

When calling rust functions from bare threads, such as C pthreads, this lock will be very
helpful. In other cases however, you are encouraged to use the locks from the standard
library.

mutex.rs

Most of this is not true anymore. This is referring to the now removed runtime that implemented green-threading for rust. Using std::sync::Mutex in a non-rust thread should be safe. I believe the only difference now a days is the poisoning and that this is no_std.

Hello, recently i become writing nostd application but i getting error while trying to unwrap .lock() how it might be fixed?

Hi, I've discovered that spin 0.9.6 is yanked, which causes our CI to complain thanks to our use of cargo deny, but I can't find any information about why it was yanked.

There don't seem to be any release notes or even a commit in https://github.com/mvdnes/spin-rs/commits/master that documents the bump to 0.9.7.

Why should it be a priority for me to stop using 0.9.6?

This safe code creates two references to the save value, one of which is mutable.

let lock = RwLock::new(1);
let read = lock.read();
for _ in 0 .. usize::MAX >> 2 {
  forget(lock.read());
}
let mut write = lock.write();

(&*read, &mut *write)

It will succeed, due to overflow in internal atomic value.

There must be protection against overflows in locking functions.
For reference, see https://docs.rs/atomicell/0.1.2/src/atomicell/borrow.rs.html#95

Hi, very good crate, it as undergone a strong improvement from the version 0.5 that is use.

As i said in the title i noticed that the lock_api feature is named lock_api1 into the code, making impossible for the users to enable that feature.

Keep it up!

In obtain_lock, would it make sense (on x86) to use the PAUSE instruction inside the loop? Looking at the Intel manuals, it seems to be designed for this kind of situation.

Right now if the builder panics, all concurrent and future Once::call_once calls will be stuck forever.

The Game Boy Advance is an ARMv4T platform with tier 3 support via the target triple thumbv4t-none-eabi. It's a single-threaded processor with no atomic instructions, so you have to use the atomic-polyfill crate and provide a custom implementation of a critical section which disables interrupts for the duration of an atomic operation.

This crate assumes it can find atomic types in the core library and therefore fails on this platform. Would you be willing to add a feature flag to support atomic-polyfill?

Hello @mvdnes I'm sorry to hear that you've lost interest in maintaining this crate 😞

I've found this crate useful and took an interest in it when I used it for a toy kernel project of mine so I'd like to offer taking up responsibility of maintaining this crate so feel free to send me a collaborator invitation or a repository transfer request 😄

Someone should investigate what, if anything, is worthwhile using in cpu_relax on non-x86 architectures.

it points to https://mvdnes.github.io/spinlock-rs/ which seems like it'd be correct, but it 404s.

I would like to be able to do a greedy readlock on the RwLock.

What I mean by a "greedy" readlock, is that when I call "read" on the RwLock, it increments the reader count (locking out future writers), but the read guard it returns will spin in the deref so that the data access is still safe.

I don't know if this would be of interest to anyone else, but I have hacked away at the RwLock implementation to fit my needs: https://gist.github.com/Visic/5c672c750e1a6e16590d9cd7dd11d1c8

My specific use case is that I need to be able to lock in the current state when some event happens (without blocking that thread), and then leaving it up to the future consumers of the lock to deal with the potential waiting. This also has an added benefit that waiting at that point is less likely, since if the write lock had been taken before, the writer might have finished before you ever actually access the data.

A further improvement could be to implement some sort of "try_deref" on the readlock, so that the readers aren't Forced to wait if they want to poll for the final result.

If this isn't of interest for this crate, please feel free to close the issue.

Does it really make sense?

I have the following type:

type IrqList = FnvIndexMap<u8, MiniVec<InterruptHandler>, 256>;
pub type InterruptHandler = Box<dyn Fn(InterruptStackFrameValue) + Send + Sync>;

However, doing this:

static IRQ_FUNCS: Lazy<IrqList> = Lazy::new(|| {
let mut table = IrqList::new();
(0 .. u8::MAX).for_each(|i| {
let v = MiniVec::<InterruptHandler>::new();
if table.insert(i, v).is_err() {
panic!("Cannot add ISR function table for interrupt {}!", i);
}
});
table
});

And then trying to modify that mutably gives me the error:

error[E0596]: cannot borrow data in a dereference of `spin::lazy::Lazy<IndexMap<u8, MiniVec<alloc::boxed::Box<dyn Fn(InterruptStackFrameValue) + Send + Sync>>, hash32::BuildHasherDefault<hash32::fnv::Hasher>, 256_usize>, fn() -> IndexMap<u8, MiniVec<alloc::boxed::Box<dyn Fn(InterruptStackFrameValue) + Send + Sync>>, hash32::BuildHasherDefault<hash32::fnv::Hasher>, 256_usize>>` as mutable
   --> src/interrupts.rs:796:26
    |
796 |     if let Some(funcs) = IRQ_FUNCS.get_mut(&interrupt) {
    |                          ^^^^^^^^^ cannot borrow as mutable
    |
    = help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `spin::lazy::Lazy<IndexMap<u8, MiniVec<alloc::boxed::Box<dyn Fn(InterruptStackFrameValue) + Send + Sync>>, hash32::BuildHasherDefault<hash32::fnv::Hasher>, 256_usize>, fn() -> IndexMap<u8, MiniVec<alloc::boxed::Box<dyn Fn(InterruptStackFrameValue) + Send + Sync>>, hash32::BuildHasherDefault<hash32::fnv::Hasher>, 256_usize>>`

Is this a problem with spin::lazy::Lazy itself? Or is this a problem with whatever is within it? This used to work with lazy_static but doesn't work like this for some reason. And DerefMut is not implemented for spin::lazy::Lazy. Is a lock more appropriate here?

RFC rust-lang/rfcs#2788 introduced a (still unstable) std::lazy module. While the Lazy and OnceCell types of this module are also available in core, their Sync counterparts are not because of their Mutex dependency.

The spin crate already provides a spin::Once as an alternative to the std::lazy::SyncOnceCell type (albeit with a different API). It would be useful if it would also provide an alternative to the std::lazy::SyncLazy type. This way, we could avoid depending on the lazy_static crate.

I'm trying to make a type that can initialize once, but get modified later. Since Once doesn't have any methods to get a mutable reference to the inner value, I had to wrap it in a RefCell. Since I'm handling the syncronisation elsewhere, I only need the type to implement Send. I can understand needing Send and Sync to implement Sync, but does the inner type really need Sync in order to implement Send? Alternatively, since I have a mutable reference to the Once value, it would be nice to have a get_mut like method that requires a mutable/unique reference.

Wonder if 0.5.1 could be released so as to get rid of build warnings (re: atomic bool init that was recently fixedin the master)?

The question is (albeit probably very unlikely to make a difference), do we even need to perform that store? Because if panic = 'unwind' then IIRC panics will only execute destructors and not code, so shouldn't we be able to simply do core::mem::forget(finish)?

Originally posted by @4lDO2 in #109 (comment)

Oh, of course. If get_unchecked_mut takes &mut self, then it would certainly make sense to implement that. But again, probably in another PR.

Originally posted by @4lDO2 in #109 (comment)

As of rustc 1.22.0-nightly (cfcac3720 2017-09-17), spin fails to build on nightly:

error: `<core::cell::UnsafeCell<T>>::new` is not yet stable as a const fn
   --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/spin-0.4.5/src/mutex.rs:123:19
    |
123 |             data: UnsafeCell::new(user_data),
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: in Nightly builds, add `#![feature(const_unsafe_cell_new)]` to the crate attributes to enable

error: `<core::cell::UnsafeCell<T>>::new` is not yet stable as a const fn
   --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/spin-0.4.5/src/rw_lock.rs:103:19
    |
103 |             data: UnsafeCell::new(user_data),
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: in Nightly builds, add `#![feature(const_unsafe_cell_new)]` to the crate attributes to enable

error: `core::sync::atomic::AtomicUsize::new` is not yet stable as a const fn
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/spin-0.4.5/src/once.rs:56:20
   |
56 |             state: AtomicUsize::new(INCOMPLETE),
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: in Nightly builds, add `#![feature(const_atomic_usize_new)]` to the crate attributes to enable

error: `<core::cell::UnsafeCell<T>>::new` is not yet stable as a const fn
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/spin-0.4.5/src/once.rs:57:19
   |
57 |             data: UnsafeCell::new(None),
   |                   ^^^^^^^^^^^^^^^^^^^^^
   |
   = help: in Nightly builds, add `#![feature(const_unsafe_cell_new)]` to the crate attributes to enable

Several PRs were merged recently that add a significant number of features to the crate. A new version for crates.io would be welcome.

Hello!

I'd like to suggest the definition of minimal permissions on your workflow, as it would harden your security agains supply-chain attacks. I see that you have only one workflow, the rust.yml, but it does not specify the permissions for its jobs, letting their privileges determined by GitHub's defaults. By defining minimal permissions you would be secured against erroneous or malicious actions from external jobs you call from your workflow. It's specially important for the case they get compromised, for example.

Setting minimum permissions for workflows is recommended by GitHub itself and also by other security tools, such as Scorecards and StepSecurity.

Let me know what you think about this. I'd be happy to raise a PR with the changes if you agree.

Context

I'm Diogo and I work on Google's Open Source Security Team(GOSST) in cooperation with the Open Source Security Foundation (OpenSSF). My core job is to suggest and implement security changes on widely used open source projects 😊

@Amanieu's parking_lot crate has a SpinWait module that implements exponential backoff. This would be a useful addition to the current implementation, and could also be exposed on its own. The latter might be useful when implementing other synchronization primitives that only need the spinning, and not the locking. There's been some discussion on this on the parking_lot issue tracker.

The biggest hurdle to adoption is that SpinWait currently yields after spinning for a while, which wouldn't work with no_std. As discussed on the parking_lot issue, this could be put behind a feature flag, or maybe even removed altogether and left to the users of the module.

try is a reserved keyword so I have to do r#try if I want to use it in Rust Edition 2018(playground link). That doesn't look very pretty. Can we rename spin::Once::try into something else so that we don't have to explicitly escape the reserved keyword?
Thanks!

Github has decent redirect support, so it would be probably safe to rename the repo to just spin.

Like std::sync::Once, except we can do better and let the closure have a return value / hand out a &.

In fact I've already written https://github.com/RustOS-Fork-Holding-Ground/lazy-static-spin/blob/spin/src/lazy.rs, a good start---and I think code would have a better home here than there.

Hello. I'd like to use this crate in Robigalia.
However, for that,

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.

But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. Stronger protections to licensees and better
interoperation with the wider Rust ecosystem is.

How?

To do this, get explicit approval from each contributor of copyrightable
work (as not all contributions qualify for copyright, due to not being a
"creative work", e.g. a typo fix. The advice the FSF uses is "less than
15 lines") and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally
submitted for inclusion in the work by you, as defined in the Apache-2.0
license, shall be dual licensed as above, without any additional terms
or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 spin-rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with:

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @mvdnes
• @Ericson2314
• @phil-opp
• @Ryman
• @arthurprs
• @cmr
• @birkenfeld
• @dpc
• @veddan

error[E0599]: no method named `compare_exchange_weak` found for struct `AtomicBool` in the current scope
   --> /home/asaveau/.cargo/registry/src/index.crates.io-6f17d22bba15001f/spin-0.9.5/src/mutex/spin.rs:179:14
    |
179 |             .compare_exchange_weak(false, true, Ordering::Acquire, Ordering::Relaxed)
    |              ^^^^^^^^^^^^^^^^^^^^^ method not found in `AtomicBool`

error[E0599]: no method named `compare_exchange` found for struct `AtomicBool` in the current scope
   --> /home/asaveau/.cargo/registry/src/index.crates.io-6f17d22bba15001f/spin-0.9.5/src/mutex/spin.rs:239:14
    |
239 |             .compare_exchange(false, true, Ordering::Acquire, Ordering::Relaxed)
    |              ^^^^^^^^^^^^^^^^ method not found in `AtomicBool`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `spin` due to 2 previous errors

On riscv32i-unknown-none-elf

Given that there are several feature requests open in the issues and that this project lies at the heart of many Rust projects, would you be open to transferring ownership of the repository & crate to someone else?

https://doc.rust-lang.org/std/sync/struct.Barrier.html is the last synchronization primitive for which I believe an equivalent in this library makes sense.

This test fails with a certain probability.

// insert this in once.rs:684
    #[test]
    fn extra() {
        use std::sync::Arc;
        use std::sync::atomic::AtomicUsize;
        use std::time::Duration;
        let share = Arc::new(AtomicUsize::new(0));
        let once = Arc::new(Once::<_, Spin>::new());
        let mut hs = Vec::new();
        for _ in 0..10 {
            let h = thread::spawn({
                let share = share.clone();
                let once = once.clone();
                move || {
                    thread::sleep(Duration::from_millis(10));
                    once.call_once(|| {
                        share.fetch_add(1, Ordering::SeqCst);
                    });
                }
            });
            hs.push(h);
        }
        for h in hs {
            let _ = h.join();
        }
        assert_eq!(1, share.load(Ordering::SeqCst));
    }

UB when try_call_once returns an error while multiple threads are attempting to access the Once. On debug builds this panics, but in release this falls back to unreachable() which is UB.

It looks like the cause is that the function expects that the state can only go from running->[complete, panicked] and doesn't take into account that it can go back to incomplete if the once function returns an error. The solution here would be retrying rather than hitting the unreachable.

Minimal Reproduce:

use std::{thread, time::Duration};

use spin::Once;

fn main() {
    let once = Once::new();

    thread::scope(|s| {
        s.spawn(|| {
            _ = once.try_call_once(|| {
                thread::sleep(Duration::from_secs(1));
                Err(())
            });
        });
        s.spawn(|| {
            thread::sleep(Duration::from_millis(10));
            once.call_once(|| {});
        });
    });
}

For example, on Linux, we could use the SCHED_YIELD system call (code 24) that would yield to the OS scheduler instead of using pause for all x86 implementations. This also has the benefit of supporting more platforms efficiently.

It would be nice to have some good example usages for each of the primitives in this crate.

If you, dear reader, happen to be interested in writing one then we'll be very happy to accept proposals!

I haven't looked into the details, but this code doesn't compile anymore with 0.4.1 whereas it used to with 0.4.0. This breaks semantic versioning.

While working on Once, I noticed that our unsafe Send and Sync impls are different from std---I am not sure why or whether its sound. [I ended up going with the RwLock ones for Once, since both give access to a &T to potentially multiple threads.]

• https://github.com/mvdnes/spinlock-rs/blob/master/src/mutex.rs#L95
• https://github.com/mvdnes/spinlock-rs/blob/master/src/rw_lock.rs#L72-L73
• https://doc.rust-lang.org/nightly/src/std/up/src/libstd/sync/mutex.rs.html#129-131
• https://doc.rust-lang.org/nightly/src/std/up/src/libstd/sync/rwlock.rs.html#75-77

I understand it's a no_std crate, but adding a Debug trait would be trivial and it'd greatly expand it's use case in non no_std projects.

Compiling spin v0.4.10
error[E0432]: unresolved import core::hint
--> C:\Users\xiaolong.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\spin-0.4.10\src\once.rs:48:11
|
48 | use core::hint::unreachable_unchecked as unreachable;
| ^^^^ Could not find hint in core

error: aborting due to previous error

If you want more information on this error, try using "rustc --explain E0432"
error: Could not compile spin.

To learn more, run the command again with --verbose.

@mvdnes I'm switching the repository CI over to GitHub actions. This will make CI automatically integrated with PRs and forks. I'm also switching the documentation in Cargo.toml over to the default docs.rs domain to avoid those using stable releases being redirected to unstable docs. I will, however, keep the documentation badge that redirects to your own URL to allow nightly docs to work fine.