cs_libguarded VS parking_lot

I know this article was trying to come up with an excuse to use a shared_ptr, but atomic smart pointers are a lot more error prone than wrapping mutexes in an appropriate interface that hides the complexity and forces you to use them correctly.

The approach I would recommend would be to use mutexes but wrap them in a convenience library designed to make them difficult to misuse: https://github.com/copperspice/cs_libguarded

I was inspired by the great copperspice library libguarded and wanted something similar for when I have to go back to micro's and FreeRTOS. The basic idea of the library is to prevent access to a shared data structure unless the mutex lock associated with it is also acquired. This is to prevent situations where someone forgets to get the lock before reading or writing to shared memory.

I'm personally partial to the basic guarded type from https://github.com/copperspice/cs_libguarded due to its simplicity.

The Rust strategy for mutexes sounds a lot like libguarded, which now that I've read this article is occurs to me that the former was likely have been the inspiration for the latter.

This is pretty much what libguarded does.

Also I don't think that operating this way is good to begin with. See how libGuard operates - it is way way cleaner and more flexible https://github.com/copperspice/cs_libguarded

have you heard of https://github.com/copperspice/cs_libguarded ? it sounds like a similar idea, but supports other stuff like rcu as well

https://github.com/copperspice/cs_libguarded#cslibguarded

Recently I've been developing my own mutex using a lot of inspiration from the excellent parking_lot crate. The mutex in parking_lot is eventually fair in that it occasionally does a fair unlock to ensure threads aren't completely starved.

parking_lot still has an open issue #201: Heavily degraded performance while in extreme contention on some processors which reveals that parking_lot selfishly uses spinning locks under some circumstances to sacriice total system efficiency in the name of trying to improve its own latency. In my opinion, the only place spinning locks are excusable is fullscreen games and, even then, Linus Torvalds is of the opinion they're usually implemented wrong. (Issue 201 also includes a bunch of benchmark runs if you want to read through to figure out which one applies to the current shipping state of the codebase.)

I think there was at some point the plan to make it the std implementation. However, cross platform support was kinda tricky if I remember link to an issue. I tend to suggest to always first prototype with std primitives. Often your bottlenecks are in totally different places. For example, you wait on some data C that also waits on data B but this depends on A which is a really slow query to a database.

I think the current state-of-the-art in terms of high-performance, general-purpose mutexes is parking_lot. (Which was ported from a C++ project of the same name.) Rather than initializing a new underlying pthread_mutex for every instance of Mutex, it keeps a global collection of thread parking queues somewhere, which turns out to be more efficient in various ways. An individual parking_lot::Mutex doesn't require a heap allocation, and is just 1 byte in size (plus the size of T).

The first was bug 1674770, which was a bug in the parking_lot library. This Rust library provides synchronization primitives and other concurrency tools and is written and maintained by experts. We did not investigate the impact but the issue was a couple atomic orderings being too weak and was fixed quickly by the authors. This is yet another example that proves how difficult it is to write bug-free concurrent code.