Support blocking and non-blocking operations on the same Mutex

[joshtriplett]

Add lock_blocking and lock_arc_blocking methods to allow sharing the
same lock between blocking and non-blocking code.

Introduce a helper macro to avoid duplicating the code of the
acquire_slow method.

[zeenix]

Thanks @joshtriplett ! LGTM. Could see check why the mini test is failing?

[zeenix]

Thanks @joshtriplett ! LGTM. Could see check why the mini test is failing?

Ah nm. @taiki-e already fixed it: #26 . Can you rebase?

[notgull]

I'm a bit concerned about this. If this crate moves to a different backing implementation of synchronization, this may include a higher burden of porting.

[joshtriplett]

@zeenix Rebased.

@notgull Support for both blocking and non-blocking seems fairly fundamental to event-listener, and I think it's an important primitive for bridging between sync and async code. This is the kind of thing I'm hoping to see in the standard library in the future: not two completely independent lock types, but one lock type that works in both sync and async code.

[notgull]

I see. I wonder if this could be done for async-channel, since that is also backed by event-listener.

[joshtriplett]

@notgull I very much hope so!

[zeenix]

@smol-rs/admins so any objections in merging this?

[fogti]

Can we factor this block of code into a separate method? It is repeated 2 times in this method with small variations in the _=> case, and with this PR applied would then be duplicated again, resulting in 5 repetitions...

[joshtriplett]

I'm not sure we can factor that into a method, since it includes control flow. I could make it a macro if you like.

[fogti]

since it includes control flow

that can be factored out, using something like the core::ops::ControlFlow, e.g.:

enum ScxResult {
    /// Lock acquired
    Acquired,
    /// Lock is held and nobody is starved
    HeldUnstarved,
    /// Somebody is starved
    Starved,
}
fn do_scx(state: &...) -> ScxResult {
    use ScxResult::*;
    match state
        .compare_exchange(0, 1, Ordering::Acquire, Ordering::Acquire)
        .unwrap_or_else(|x| x)
    {
        0 => Acquired,
        1 => HeldUnstarved,
        _ => Starved,
    }
}

[notgull]

Maybe we could refactor this into a trait, like I did for the OnceCell in #27.

[taiki-e]

I think a caveat like "calling this method on async code may cause deadlock" would be nice. Otherwise LGTM.

I wonder if this could be done for async-channel, since that is also backed by event-listener.

I would accept a PR that does this.

[dignifiedquire]

What's needed for getting this in?

It would also be super useful to have this for RwLock.

[notgull]

What's needed for getting this in?

It would also be super useful to have this for RwLock.

It would need a rebase, among other things. I've opened #39 as a replacement that also implements blocking ops for the other lock types.

[notgull]

Closed by #56