4 ms·

Seems like the simple solution to this problem would be to have both, no? A simple native lock in the standard library along with a nicer implementation (also

by strbean 11mo ago

Seems like the simple solution to this problem would be to have both, no? A simple native lock in the standard library along with a nicer implementation (also in the standard library) that depends on the simple lock?

loeg 11mo ago
My takeaway is that the documentation should make more explicit recommendations depending on the situation -- i.e., people writing custom allocators should use std mutexes; most libraries and allocations that are ok with allocation should use parking_lot mutexes; embedded or libraries that don't want to depend on allocate should use std mutexes. Or maybe parking_lot is almost useless unless you're doing very fine-grained locking. Something like that.
scottlamb 11mo ago
The simplest solution is for `std::mutex` to provide a simple, efficient mutex which is a good choice for almost any program. And it does. Niche programs can pull in a crate. I doubt `parking_lot` would have been broadly used—maybe wouldn't even have been written—if `std` had this implementation from the start. What specifically in this comparison made you think that `parking_lot` is broadly needed? They had to work pretty hard to find a scenario in which `parking_lot` did much better in any performance metrics. And as I alluded to in another comment, `parking_lot::Mutex<InnerFoo>` doesn't have a size advantage over `std::mutex::Mutex<InnerFoo>` when `InnerFoo` has word alignment. That's the most common situation, I think. If I were to make a wishlist of features for `std::mutex` to just have, it wouldn't be anything `parking_lot` offers. It'd be stuff like the lock contention monitoring that the (C++) `absl::Mutex` has. (And at least on some platforms you can do a decent job of monitoring this with `std::mutex` by monitoring the underlying futex activity.)
- torginus 11mo ago
  This. the standard library has a responsibility to provide an implementation that performs well enough in every possible use case, while trying to be generally as fast as possible.
- strbean 10mo ago
  With zero prior knowledge of the context, the impression I got from the parent comment was that `parking_lot` had features that made it desirable enough that there was a decent amount of discussion about replacing the standard lib locks with it. I didn't catch that the previous standard lib option was terrible and has since been replaced with something better.

by strbean 11mo ago

loeg 11mo ago

My takeaway is that the documentation should make more explicit recommendations depending on the situation -- i.e., people writing custom allocators should use std mutexes; most libraries and allocations that are ok with allocation should use parking_lot mutexes; embedded or libraries that don't want to depend on allocate should use std mutexes. Or maybe parking_lot is almost useless unless you're doing very fine-grained locking. Something like that.

scottlamb 11mo ago

The simplest solution is for `std::mutex` to provide a simple, efficient mutex which is a good choice for almost any program. And it does. Niche programs can pull in a crate. I doubt `parking_lot` would have been broadly used—maybe wouldn't even have been written—if `std` had this implementation from the start. What specifically in this comparison made you think that `parking_lot` is broadly needed? They had to work pretty hard to find a scenario in which `parking_lot` did much better in any performance metrics. And as I alluded to in another comment, `parking_lot::Mutex<InnerFoo>` doesn't have a size advantage over `std::mutex::Mutex<InnerFoo>` when `InnerFoo` has word alignment. That's the most common situation, I think. If I were to make a wishlist of features for `std::mutex` to just have, it wouldn't be anything `parking_lot` offers. It'd be stuff like the lock contention monitoring that the (C++) `absl::Mutex` has. (And at least on some platforms you can do a decent job of monitoring this with `std::mutex` by monitoring the underlying futex activity.)

torginus 11mo ago
This. the standard library has a responsibility to provide an implementation that performs well enough in every possible use case, while trying to be generally as fast as possible.
strbean 10mo ago
With zero prior knowledge of the context, the impression I got from the parent comment was that `parking_lot` had features that made it desirable enough that there was a decent amount of discussion about replacing the standard lib locks with it. I didn't catch that the previous standard lib option was terrible and has since been replaced with something better.