4 ms·
Yes you need both compiler barriers for the ordering, as well as memory fences to ensure the global visibility of previous operations in order. It is possible t
by BagOfPistchios 8y ago
Yes you need both compiler barriers for the ordering, as well as memory fences to ensure the global visibility of previous operations in order.
It is possible that the mutex implementation he used does no spinning in case of contention and just context switches each time. That could explain the poor performance of mutexes but I don't know the implementation.
- Jonhoo 8y agoThe mutexes were standard Rust Mutex, which I believe just forwards directly to pthread locks. I'm not sure what kind of spinning behavior they have though.
- the_mitsuhiko 8y agoRust mutexes are in the process of being redone. The popular parking-lot library js about to replace the platform native ones.
- Jonhoo 8y agoMy hunch would be that the results from the talk wouldn't materially change, except that the Mutex numbers would perhaps be _slightly_ better. The scalability issue would remain though, as it is fundamental to mutexes!
- kibwen 8y agoCan you link to the discussion this is referencing? I can't imagine parking_lot outright replacing the mutex in std, rather than being added as an optional alternative... what would be the supported way of deliberately using the platform-native mutex?
- the_mitsuhiko 8y agoThe discussion is partially here: https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439 https://internals.rust-lang.org/t/standard-library-synchroni... The PR for std is here: https://github.com/rust-lang/rust/pull/56410 https://github.com/rust-lang/rust/pull/56410 Mostly comes to the platform native APIs habing various soundness issues.
- gamegoblin 8y agoparking-lot mutexes don't support lock poisoning like the standard library mutexes. Wouldn't this be a totally breaking change? Unless poisoning has been added to parking-lot?