#mutex #thread #waiting #priority #specify

priomutex

A mutex where waiting threads specify a priority

8 releases

Uses old Rust 2015

0.3.1 Apr 10, 2018
0.3.0 Apr 3, 2018
0.2.3 Apr 3, 2018
0.2.1 Mar 16, 2018
0.1.1 Jan 26, 2018

#598 in Concurrency

Download history 1/week @ 2024-04-05 4/week @ 2024-04-19 29/week @ 2024-04-26 7/week @ 2024-05-03 113/week @ 2024-06-21 12/week @ 2024-06-28 3/week @ 2024-07-05 6/week @ 2024-07-12 20/week @ 2024-07-19

55 downloads per month

MIT/Apache

17KB
233 lines

priomutex: a mutex where waiting threads specify a priority

The API is very similar to std::sync::Mutex. The key difference, of course, is that lock() takes a priority. If multiple threads are waiting for the mutex when it's freed, the one which gave the highest priorty will recieve it.

impl<T> Mutex<T> {
    fn new(data: T) -> Mutex<T>;
    fn lock(&self, prio: usize) -> LockResult<MutexGuard<T>>;
    fn try_lock(&self) -> TryLockResult<MutexGuard<T>>;
}

impl<T> Drop for MutexGuard<T>;      // Releases the lock
impl<T> Deref for MutexGuard<T>;     // For accessing your data
impl<T> DerefMut for MutexGuard<T>;  // For accessing your data

This crate also includes a high-performance variant in the spin_one module, which spins the highest-priority waiting thread. This makes releasing the mutex very fast, because it never needs to do any syscalls.

Status

There is no unsafe code used in either variant, so there's no possibility of two threads holding the mutex at the same time. Bugs may lead to deadlocks or non-priority-order locking, however. I'm not currently aware of any such bugs.

Benchmarking locking time is difficult. Release time, however, can be reliably measured:

simple:   2887 ns
spin_one:  248 ns

(Intel Core i7-4790K CPU @ 4.00GHz, max_cstate = 0)

Licence

Licensed under either of the following, at your option:

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

No runtime deps