6 ms·

To observe the "epoch counters" between threads (which can run on different cores), don't you still need memory fences/barriers to make the epochs visible to ot

To observe the "epoch counters" between threads (which can run on different cores), don't you still need memory fences/barriers to make the epochs visible to other threads - which I found is a significant part of the cost of locking. Perhaps that accounts for "only" 25m reads/s, although I'm surprised that mutexes are sooo much slower.

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 ago
  The 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 ago
    Rust mutexes are in the process of being redone. The popular parking-lot library js about to replace the platform native ones.
    - Jonhoo 8y ago
      My 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 ago
      Can 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 ago
        The 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 ago
      parking-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?
Jonhoo 8y ago
Yup, some synchronization is certainly necessary there too. Take a look at the full code for the read path here if you're curious! https://github.com/jonhoo/rust-evmap/blob/d307999c1ad78d10ecb6ea911b6e94d36bc841ca/src/read.rs#L85 https://github.com/jonhoo/rust-evmap/blob/d307999c1ad78d10ec...

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 ago
The 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 ago
  Rust mutexes are in the process of being redone. The popular parking-lot library js about to replace the platform native ones.
  - Jonhoo 8y ago
    My 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 ago
    Can 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 ago
      The 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 ago
    parking-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?

Jonhoo 8y ago

Yup, some synchronization is certainly necessary there too. Take a look at the full code for the read path here if you're curious! https://github.com/jonhoo/rust-evmap/blob/d307999c1ad78d10ecb6ea911b6e94d36bc841ca/src/read.rs#L85 https://github.com/jonhoo/rust-evmap/blob/d307999c1ad78d10ec...