3 ms·

> Your single threaded RC will still have to write back to memory I think you mean mem or cache, and there's a good chance it will remain in cache and not be f

> Your single threaded RC will still have to write back to memory I think you mean mem or cache, and there's a good chance it will remain in cache and not be flushed to ram for short lived objects. > no one thinks that incrementing an integer is the slow part — destroying cache is. agreed

kaba0 4y ago
If you write to cache, then depending on architecture that change has to be made visible to every other thread as well. Reading is not subject to such a constraint.
- NobleExpress 4y ago
  MESI cache coherency (and its derivatives) [1] means that you can have exclusive writes to cache if and only if no other core tries to access that data. I would think most if not all microarchitectures have moved to MESI (or equivalent) cache coherency protocols as they avoid unnecessary writes to memory. [1]: https://en.wikipedia.org/wiki/MESI https://en.wikipedia.org/wiki/MESI
  - kaba0 4y ago
    Sure, but for shared objects you can’t allow data races.
    - vlovich123 4y ago
      Objects shared across threads. Most don’t need to be.
    - _a_a_a_ 4y ago
      I don't understand the relevance of this.
- vlovich123 4y ago
  Only for atomics. Single-threaded RC counts are fine and WebKit uses hybrid RC where you use an atomic shared ptr to share across threads and then you downgrade it to a non atomic version in-thread (and can hand out another atomic copy at any time). Atomics are rarely needed as you should really try to avoid sharing ownership across threads and instead change your design to avoid that if you can.
  - _a_a_a_ 4y ago
    >> If you write to cache, then depending on architecture that change has to be made visible to every other thread as well > Only for atomics I don't think cache coherency is aware of threads; they live at a level above it (IANAExpert though) > where you use an atomic shared ptr to share across threads and then you downgrade it to a non atomic version in-thread (and can hand out another atomic copy at any time). your idea of GC is very different from others', you are happy to do a ton of manual stuff. GC is generally about not doing a ton of manual stuff.

kaba0 4y ago

If you write to cache, then depending on architecture that change has to be made visible to every other thread as well. Reading is not subject to such a constraint.

NobleExpress 4y ago
MESI cache coherency (and its derivatives) [1] means that you can have exclusive writes to cache if and only if no other core tries to access that data. I would think most if not all microarchitectures have moved to MESI (or equivalent) cache coherency protocols as they avoid unnecessary writes to memory. [1]: https://en.wikipedia.org/wiki/MESI https://en.wikipedia.org/wiki/MESI
- kaba0 4y ago
  Sure, but for shared objects you can’t allow data races.
  - vlovich123 4y ago
    Objects shared across threads. Most don’t need to be.
  - _a_a_a_ 4y ago
    I don't understand the relevance of this.
vlovich123 4y ago
Only for atomics. Single-threaded RC counts are fine and WebKit uses hybrid RC where you use an atomic shared ptr to share across threads and then you downgrade it to a non atomic version in-thread (and can hand out another atomic copy at any time). Atomics are rarely needed as you should really try to avoid sharing ownership across threads and instead change your design to avoid that if you can.
- _a_a_a_ 4y ago
  >> If you write to cache, then depending on architecture that change has to be made visible to every other thread as well > Only for atomics I don't think cache coherency is aware of threads; they live at a level above it (IANAExpert though) > where you use an atomic shared ptr to share across threads and then you downgrade it to a non atomic version in-thread (and can hand out another atomic copy at any time). your idea of GC is very different from others', you are happy to do a ton of manual stuff. GC is generally about not doing a ton of manual stuff.