Support custom mutexes via `lock_api` on `no_std`

[Martin Kröning]

I would like to use once_cell in libhermit-rs, a kernel with SMP support where neither spinning nor using critical-section alone would be sufficient. (spinning alone does not work because of interrupts, critical sections are not ideal as they are global and not parallel)

A design using lock_api would allow us to provide our own mutex implementation via a generic type parameter on OnceCell and Lazy:

impl OnceCell<R: lock_api::RawMutex ,T> {
    // Creates a lock_api::Mutex from RawMutex::INIT.
    fn new() -> OnceCell<R, T> { ... }
    fn set(&self, value: T) -> Result<(), T> { ... }
    fn get(&self) -> Option<&T> { ... }
}

With this, it would also be possible to use spin-rs if one would really want to (#61).

Would you be open to such an approach, @matklad? I could start working on a PR.

[Alex Kladov]

My gut feeling is that it's better to publish this as a separate crate: types in once_cell are deliberately non-parametric, it just uses the "default" synchronization. Would be happy to advertise that from Readme!

So, for example, if the leaf crate opts into critical section, than all upstream crates would also use critical_section, without any code changes.

A once-cell parametrized over locking API would certainly be a useful thing! But it's fundamentally a different design.

What would work for this crate is critical_section-like setup, but with real mutexes. That is, using some linker magic to inject an overridable implementation of mutexes. I don't know whether such things exist.

[Martin Kröning]

I understand. Thanks for your quick reply! :)

I think, I'll go for a separate crate based on once_cell then. That way, we are able to use different mutex implementations at different places.

Would you prefer a name without reference to once_cell like lock_cell instead of something like once_cell_lock_api? Would you rather keep this issue open until the crate is published and referenced in the Readme or close it now, since the issue itself is out of scope for once_cell?

[Alex Kladov]

Would you prefer a name without reference to once_cell like lock_cell instead of something like once_cell_lock_api?

No opinion

Would you rather keep this issue open until the crate is published and referenced in the Readme or close it now, since the issue itself is out of scope for once_cell?

let's keep it open