bert/tracing-mutex
1
0
Fork 0
mirror of https://github.com/bertptrs/tracing-mutex.git synced 2025-12-25 12:40:31 +01:00
Code Issues Projects Releases Wiki Activity

Update README

Browse Source
This commit is contained in:
Bert Peters
2021-05-24 15:30:56 +02:00
parent 40e40f658c
commit 917906e85e
1 changed files with 5 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@@ -2,7 +2,7 @@
[![Continuous integration](https://github.com/bertptrs/tracing-mutex/actions/workflows/ci.yml/badge.svg)](https://github.com/bertptrs/tracing-mutex/actions/workflows/ci.yml)
[![Crates.io](https://img.shields.io/crates/v/tracing-mutex.svg)](https://crates.io/crates/tracing-mutex)
[![Documentation](https://img.shields.io/docsrs/tracing-mutex.svg)](https://docs.rs/tracing-mutex)
[![Documentation](https://docs.rs/tracing-mutex/badge.svg)](https://docs.rs/tracing-mutex)
Avoid deadlocks in your mutexes by acquiring them in a consistent order, or else.
@@ -18,6 +18,10 @@ should first acquire `Foo` then you can never deadlock. Of course, with just two
easy to keep track of, but once your code starts to grow you might lose track of all these
dependencies. That's where this crate comes in.
This crate tracks the order in which you acquire locks in your code, tries to build a dependency
tree out of it, and panics if your dependencies would create a cycle. It provides replacements for
existing synchronization primitives with an identical API, and should be a drop-in replacement.
Inspired by [this blogpost][whileydave], which references a similar behaviour implemented by
[Abseil][abseil-mutex] for their mutexes.