How fast the system makes updates has nothing to do with it.
Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers.
Naive sequence:
1. Alice: READ STATE => foo
2. Bob: READ STATE => foo
3. Alice: SET STATE=bar
4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work.
The solution is that instead of a naive "set", to use "test-and-set" operation.
Bob may or may not be concerned with what the state is/was, and more concerned with what state the system needs to converge on.
I take your point, although the assumption is that Bob wants to set state=baz IFF (if and only if) state==foo. However he may simply need the state to be baz, regardless what the previous state was.
Many systems (especially caching systems) make a point of differentiating the `set` operation from a `check and set` operation (usually known as `cas`) in systems where both of these operations are available you are quite able to intelligently differentiate those two resolution states.
Premise: The current state is "foo". Alice would like to change the state to "bar". Bob would like to change the state to "baz". Alice and Bob are friendly (non-antagonistic) coworkers.
Naive sequence:
1. Alice: READ STATE => foo
2. Bob: READ STATE => foo
3. Alice: SET STATE=bar
4. Bob: SET STATE=baz <-- this is where the "confusing"/"wrong" thing happened. Bob did not expect to overwrite his coworker's work.
The solution is that instead of a naive "set", to use "test-and-set" operation.