Testing spinlock with Loom

[cmnord]

I am trying to model a spinlock with Loom and running into a similar issue to #52 and #115. In particular, if I run my test loom with

RUSTFLAGS="--cfg loom" RUST_BACKTRACE=1 cargo test --test loom -- --test-threads=1 --nocapture

I get thread panicked while panicking. aborting. because Model exeeded maximum number of branches. This is often caused by an algorithm requiring the processor to make progress, e.g. spin locks..

#52 says:

the value of max_branches is to avoid an infinite loop when trying to model concurrent algorithms that are unbounded. For example, if you have a spin lock, if the thread that is spinning never yields, the model can go forever. If you have a legit case, you can increase the value of max_branches.

Does that mean that I can't test my spinlock with Loom, or do I need to add something to my spinlock implementation or my test to make it work with Loom? My spinlock implementation and Loom code are in this branch.

Thanks!

[hawkw]

Try increasing the value of max_branches by a bit?

[carllerche]

You need to yield in the loop before retrying: https://docs.rs/loom/0.3.5/loom/thread/fn.yield_now.html

This tells loom there is a loop going on and to try some other branches.

[tower120]

So how did you test spinlocks in the end? I tried yield_now, but that's incredibly slow. (like tens of minutes)

[Darksonn]

Loom is slow. Tokio's CI setup takes more than an hour because that's how long time our slowest loom test takes. You could try to mess with LOOM_MAX_PREEMPTIONS to have it test less of the state space.

[tower120]

I see, thanks. You should add note about hour-scale "slow" in the docs. I was confident that it hang up.

[tower120]

BTW, can it, theoretically, become multi-threaded?

[Darksonn]

Yes, but nobody has put in the work.

Generally, loom will print the iteration number as it runs, so you can use that to see whether it has hung up. (If running in test, make sure to enable prints in the test.)

[tower120]

It does show! But for me, it just output everything at once, once test done.
Maybe, that's just how clion+rust console work though...

Thanks, I'll try with "pure" console.

[jneem]

I had a similar issue involving a spin lock, and when I tried to minimize the problem I ran into some surprising (to me, an atomics novice) difference between the behavior of swap and compare_exchange. Specifically, the following spin lock fails loom tests with "Model exceeded maximum number of branches":

use loom::hint;
use loom::sync::atomic::AtomicBool;
use std::sync::atomic::Ordering::{Acquire, Relaxed, Release};

pub struct Lock {
    locked: AtomicBool,
}

impl Lock {
    pub fn lock(&self) {
        while self.locked.swap(true, Acquire) {
            hint::spin_loop();
        }
    }

    pub fn unlock(&self) {
        self.locked.store(false, Release);
    }
}

#[test]
fn test_concurrent_logic() {
    loom::model(|| {
        let v1 = loom::sync::Arc::new(Lock::new());
        let v2 = v1.clone();
        let t1 = thread::spawn(move || {
            v2.lock();
            v2.unlock();
        });

        v1.lock();
        v1.unlock();

        t1.join().unwrap();
    });
}

But if I change while self.locked.swap to while self.locked.compare_exchange_weak(false, true, Acquire, Relaxed).is_err() then the tests succeed. Shouldn't these two things have the same behavior (the Rust Atomics book uses "swap" in its spin lock example)?

[Darksonn]

Using swap adds a new value to the history, which a failing compare_exchange_weak does not do.