[sunshowers]

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]

> 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]

This is equivalent to giving up a lock in between though, I think.

[fc417fc802]

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.

[sunshowers]

> 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.

[pbh101]

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-condi...

‘Not thread safe’ really means ‘not thread safe’.

[gf000]

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.