Export low-level common interfaces for mutex, condvar, etc.

[avieth]

I'd like to work directly with std::sys_common mutex and condvar types. Is there any way to do this short of a custom rustc build with a modified standard library?

[jonas-schievink]

What's your use case for this? These APIs might be replaced in the future, and libstd might stop using OS primitives for this completely.

[avieth]

What's your use case for this?

The std::sync::Mutex is good about ensuring every lock is also unlocked. But I'm interested in making an abstraction which ensures the programmer can never double-lock (but could of course forget to unlock). The idea is that locking the mutex takes ownership of the mutex, rather than a reference to it, and the only way to get the mutex back is to unlock that thing. Something like

// Just like the std::sync:Mutex.
struct Mutex<T> {
  sys_mutex: ...,
  cell: UnsafeCell<T>
}

impl<T> Mutex<T> {
  pub fn lock(self) -> Locked<T> {
    // do actual low-level OS mutex lock
    self.sys_mutex.lock();
    return Locked { locked_mutex: self };
  }
}

struct Locked<T> {
  locked_mutex: Mutex<T>
}

impl<T> Locked<T> {
  pub fn unlock(self) -> Mutex<T> {
    // Do low-level OS mutex unlock
    self.locked_mutex.sys_mutex.unlock();
    return self.locked_mutex;
  }
}

impl<T> Deref for Locked<T> { ... }
impl<T> DerefMut for Locked<T> { ... }

Of course it's possible I just don't know how to do what I want. I found that, with the std interface, because the MutexGuard has a reference to the Mutex, it's impossible create the abstraction that I want; the programmer can always keep the Mutex around after calling lock(); I can't move it to the same struct as the guard.

[jonas-schievink]

It sounds like what you want is an interface for raw (non-guard) locking/unlocking of the mutex. This sounds more reasonable to expose than sys_common, and should just be 2-3 functions (or 1, if you're fine with leaking a MutexGuard).

[avieth]

Sure, it doesn't have to be the sys_common interface. Something with lock, try_lock, and unlock, where locking doesn't make a MutexGuard, would be enough I think. But then, I'd also want to use Condvars, but those require a MutexGuard.

[sfackler]

How would you ever be able to call Mutex::lock when you don't have unique access to the Mutex?

[avieth]

How would you ever be able to call Mutex::lock when you don't have unique access to the Mutex?

I only posted a rough sketch of an implementation. Really I'd want to wrap the whole thing in an Arc so it can be cloned and moved to other threads, then use an unsafe raw pointer dereference of Arc::into_raw, casting to the underlying mutex type. I think this would all be safe.

Then when unlocking, Arc::from_raw would be used to get back to the original mutex type on which lock was called.

But then, with that setup you can still double-lock, by cloning it again in the same thread and locking that thing. Hm...

[sfackler]

You can base your API off of parking_lot's RawMutex etc to avoid blocking on this request, BTW.