3 ms·

Unsynchronized, shared, mutable state are where data races happen. You need all three. This means there are three ways to resolve this: * Add synchronization

Unsynchronized, shared, mutable state are where data races happen. You need all three. This means there are three ways to resolve this: * Add synchronization with locks, etc. * Don't share mutable access, e.g. single-owner model with channels. * Make data immutable: an insight originally from purely functional languages. I believe Google invested quite heavily in this model with Guava. Rust lets you choose which one of the three to give up, and it also statically prevents all three from happening at the same time.

fc417fc802 2y ago
> Don't share mutable access, e.g. single-owner model with channels. That can still break if a reader makes multiple calls and implicitly assumes that the data structure at large hasn't been mutated between them.
- sunshowers 2y ago
  This is equivalent to giving up a lock in between though, I think.
  - fc417fc802 2y ago
    Maybe I misunderstood. I took the first bullet to refer to wrapping operations in a lock and the second to refer to single writer multiple reader. At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. Fixing it sucks because you usually have to go and add locking to your previously fast and efficient lock free setup.
    - pbh101 2y ago
      It can also break if the read implementation has mutable side effects, e.g. rebalancing. Java HashMap used to have this causing an infinite loop. I haven’t looked recently but my guess is it still does. https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html https://mailinator.blogspot.com/2009/06/beautiful-race-condi... ‘Not thread safe’ really means ‘not thread safe’.
    - sunshowers 2y ago
      > At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. This is true -- generally the solution to this is to ask for everything in a single message.
  - gf000 2y ago
    I mean, that's the "art of the deal". If you have a lock for all eternity, then you have a single owner, and are practically single-threaded. The hard part is exactly all the combinations locks can be hold and given up, which will have a non-trivial number for more complex programs/data structures. That's where modeling software can help by iterating over all the possible cases.

fc417fc802 2y ago

> Don't share mutable access, e.g. single-owner model with channels. That can still break if a reader makes multiple calls and implicitly assumes that the data structure at large hasn't been mutated between them.

sunshowers 2y ago
This is equivalent to giving up a lock in between though, I think.
- fc417fc802 2y ago
  Maybe I misunderstood. I took the first bullet to refer to wrapping operations in a lock and the second to refer to single writer multiple reader. At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. Fixing it sucks because you usually have to go and add locking to your previously fast and efficient lock free setup.
  - pbh101 2y ago
    It can also break if the read implementation has mutable side effects, e.g. rebalancing. Java HashMap used to have this causing an infinite loop. I haven’t looked recently but my guess is it still does. https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html https://mailinator.blogspot.com/2009/06/beautiful-race-condi... ‘Not thread safe’ really means ‘not thread safe’.
  - sunshowers 2y ago
    > At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though. This is true -- generally the solution to this is to ask for everything in a single message.
- gf000 2y ago
  I mean, that's the "art of the deal". If you have a lock for all eternity, then you have a single owner, and are practically single-threaded. The hard part is exactly all the combinations locks can be hold and given up, which will have a non-trivial number for more complex programs/data structures. That's where modeling software can help by iterating over all the possible cases.