Very nice article. Well written with the exception of a few typos. With respect to the conclusions, from your benchmarks it seems to me that parking lot mutexes only give advantage in that bursty situation and, unless one really knows their performance behavior matches, in most other case std mutex performance is much better. So, seems to me like using it outside of that very known behavior situation would be unwise.
Rust stdlib should really adopt the global queue approach of parking_lot to have a 2-byte lock (1 extra byte for tracking posion, though I suppose the new poison-less lock can be as small as parking_lot!)
Another great thing about parking_lot is its RwLock, which can upgrade a read-only shared lock to exclusive read-write lock.
Very nice article. Well written with the exception of a few typos. With respect to the conclusions, from your benchmarks it seems to me that parking lot mutexes only give advantage in that bursty situation and, unless one really knows their performance behavior matches, in most other case std mutex performance is much better. So, seems to me like using it outside of that very known behavior situation would be unwise.
On scenario 4 - Performance Metrics you have mean wait time inverted. 612 us is 7.5x better than 6.1ms but it's coded as a winner "std".
Rust stdlib should really adopt the global queue approach of parking_lot to have a 2-byte lock (1 extra byte for tracking posion, though I suppose the new poison-less lock can be as small as parking_lot!)
Another great thing about parking_lot is its RwLock, which can upgrade a read-only shared lock to exclusive read-write lock.