My library needs Mutex and RwLock ( sync not async ). I could use std::sync.
But it seems there are other options, such as parking_lot ( which I am experimenting with ), which claims it is "More compact and efficient implementations of the standard synchronization primitives."
One thing I noticed, in my example/test program, the crates I am using depend on parking_lot. That seems to be a positive.
Are there any downsides to using parking_lot? Are there other possibilities I should consider?
I'd say the usual advice applies: measure before optimizing. I'd be wary of adding dependencies in the hope of claimed/imagined performance improvements. parking_lot also comes with some caveats (e.g. it doesn't support wasm on the stable channel), which might be a problem in specific cases. I'm not specifically recommending against it, what I'm trying to say is it's not as simple as "import parking_lot and make everything faster automatically".
I found this: Use the parking_lot locking primitives by faern · Pull Request #56410 · rust-lang/rust · GitHub
Not sure what it means exactly, and whether it has happened, is not going to happen, or may still happen.
After changing my mind a few times, I have decided to not use parking_lot, at least for the time being. I don't think any performance difference will be significant for my use case, and I think it's better on balance to avoid the dependency and opt for simplicity.
The problem with this PR is not how outdated it is towards master. What is holding it back is how
parking_lotis currently not meeting the quality standards of the standard library and won't be accepted as a part of it right now.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.