p-avital / no-deadlocks Goto Github PK

no_deadlocks seems wrongly judge about deadlock when deal with threads, here is the test code.

use std::time::Duration;
use std::sync::Arc;

// the test code run alright
// use std::sync::Mutex;

// no_deadlocks report deadlock error
use no_deadlocks::prelude::*;

fn main() {
    let mut childs = vec![];
    let m = Arc::new(Mutex::new(0));
    for _ in 1..=10 {
        let clone_m = m.clone();
        childs.push(std::thread::spawn(move||{
            let mut m = clone_m.lock().unwrap();
            std::thread::sleep(std::time::Duration::from_secs(1));
            *m = 1;
        }))
    }
    for c in childs.into_iter() {
        c.join();
    }
}

hey, this package is pretty awesome!
I tried both this and parking_lot, but I love how you keep the original lock stack frame also. (for re-entrancy issues)

I discovered in moving some code from std::sync::Mutex to this, that std::default::Default is not
implemented on the Mutex here.

Let me know if you'd like a PR, I'm pretty new to Rust, but think I might be able to hack this.

If I understand it correctly, everytime a lock could not be taken the analyze() function is called. This is probably responsible for the huge slowdown. Maybe it is possible to analyze the graph only after for a certain (configurable) time the lock could not be taken?
Currently I'm not successful in reproducing my deadlock.

Sometimes (3 out of 20 times cargo test) it happens that requests.get(...).unwrap() in handle_deadlock panics:

test lock_manager::with_deadlock ... FAILED

failures:

---- lock_manager::with_deadlock stdout ----
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/lock_manager.rs:226:102
note: test did not panic as expected

failures:
    lock_manager::with_deadlock

Cool crate!
When using it, I had to modify Mutex to add a line like https://doc.rust-lang.org/src/std/sync/mutex.rs.html#182 from the std Mutex implementation, as I was using a data type that was Send but not Sync.
I opened this issue as it seems like the API difference from std might be a bug.
Best,
Nathan

For now, the synchronisation mechanisms should work, but deadlock detection is still awaiting implementation.
Until this is done, this crate is just slow locks