parking_lot VS proptest

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.

proptest: Property-based testing with random input generation.

Isn't proptest something that could handle this?

https://github.com/proptest-rs/proptest

Proptest is a Rust crate for property-based testing. Recently I wanted/needed to manually implement a proptest strategy for my own type, and I realized that there is not that much material on how to do it. So I wrote a post where I tried to describe what I learned. It's a bit niche, but I hope that someone at some point will find it useful.

Take a look at proptest.

Yes exactly, you can also add to this fuzzing and property based testing.

proptest is great! It generates random input data according to some rules, and if the input fails it saves random seed into a file so that failing inputs are guaranteed to be tested on the subsequent runs (as well as new random inputs). It also doesn't immediately stop on fail but tries to find a minimal failing input first.

The only other crate I could find is proptest, but it looks a lot more complicated, and I don't know if lets you skip the shrinking step as quickcheck does. I've been reading the book and going through the docs, but a quick answer would be appreciated.

We just released proptest 1.1.0, a property-testing framework for Rust. Proptest has recently found new maintainers, and this marks the first new release of proptest in ~2 years.

Hi, I'm working on a fuzzer, that fuzzes APIs based on OpenAPI specification. I'd like to implement shrinking. It means that when an interesting input (for the API) is found, I'd like to create the smallest possible input that still causes the same behaviour of the API. I'd like to implement a payload generation via proptest, because it already has the shrinking ability. I'm having issues implementing the JSON object as a proptest strategy. Here is what I tried so far. I explained it in a detail in stackoverflow question but it did not reach many people. Thanks for your help!

Third, if you're opting out of a compile-time safety guarantee in the name of performance, test heavily (high-coverage unit tests, property testing, fuzzing, differential fuzzing, etc.) and make use of tools like Loom and Miri's runtime data race detector for unsafe code, which can catch stuff that is beyond the scope of the compiler's guarantees.