#locks #mutex #synchronization #rc

guardian

Provides owned mutex guards for refcounted mutexes

5 releases (3 stable)

Uses old Rust 2015

1.0.2 Mar 7, 2022
1.0.1 Dec 4, 2018
1.0.0 Jan 30, 2017
0.3.1 Jan 30, 2017
0.3.0 Jun 21, 2016

#454 in Concurrency

Download history 15/week @ 2022-11-26 12/week @ 2022-12-03 19/week @ 2022-12-10 20/week @ 2022-12-17 14/week @ 2022-12-24 29/week @ 2022-12-31 22/week @ 2023-01-07 29/week @ 2023-01-14 39/week @ 2023-01-21 29/week @ 2023-01-28 19/week @ 2023-02-04 37/week @ 2023-02-11 23/week @ 2023-02-18 44/week @ 2023-02-25 71/week @ 2023-03-04 117/week @ 2023-03-11

260 downloads per month

MIT/Apache

25KB
330 lines

guardian

Crates.io Documentation Build Status

Guardian provides owned mutex guards for refcounted mutexes.

Normally, lock guards (be it for Mutex or RwLock) are bound to the lifetime of the borrow of the underlying lock. Specifically, the function signatures all resemble: fn lock<'a>(&'a self) -> Guard<'a>.

If the mutex is refcounted using an Rc or an Arc, it is not necessary for the guard to be scoped in this way -- it could instead carry with it a ref to the mutex in question, which allows the guard to be held for as long as is necessary. This is particularly useful for writing iterators where it is advantageous to hold a read lock for the duration of the iteration.

Poisoning

When taking a lock using a guardian, similarly to when taking an RwLock or Mutex, the result may be poisoned on panics. The poison is propagated from that of the underlying lock() method, so for RwLocks, the same rule applies for when a lock may be poisioned.

No runtime deps