0

I have this situation where I have a state variable; int state = (2, 1, 0) and an infinite loop:

ret = BoolCompareAndSwap(state, 1, 2)
if (ret) {
    // Change something ...
    state = 0;
}

Would this state setting be atomic? Assuming to set a variable you must:

  1. Take out from memory
  2. Change value
  3. Set new value

If some other thread came and compared the variable, it would be atomic since the actual value doesn't change until it it re-set in memory, Correct?

Whiteclaws
  • 902
  • 10
  • 31
  • See this [question](https://stackoverflow.com/questions/25319825/how-to-use-atomic-variables-in-c) that was asked previously about atomic variables. The order of the state setting would be dependant on how threading is done, i.e. make it thread safe. – t0mm13b Jun 05 '17 at 22:45

1 Answers1

0

Strictly speaking, C compilers would still be standard conforming if they wrote the state bitwise. After writing the first few bits, some other thread can read any kind of garbage.
Most compilers do no such thing (with the possible exception of compilers for ancient 4bit processors or even narrower ...), because it would be a performance loss.

Also, and more practically relevant, if any other thread writes (instead of only reading) to the state, that written value can get lost if you do not protect the described code against racing conditions.

As a side note, the described state change (read, modify, write) is never atomic. The question however when that non-atomicity is vulnerable, is valid and it is what I tried to answer above.

More generically speaking, thinking through all possible combinations of concurrent access is a valid protection mechanism. It is however extremely costly in many ways (design effort, test effort, risk during maintenance...).
Only if those costs are in total smaller than the intended saving (possibly performance), it is feasible to go that way, instead of using an appropriate protection mechanism.

Yunnosch
  • 26,130
  • 9
  • 42
  • 54
  • Well, Assuming CompareAndSwap will not yield true if what is read is trash, and that the other threads will only act on the above state if it is in fact 0, could you say that the state variable is protected from it being set as an intermediate value? That would make the most sense for me... (The above variable is only accessed by other threads if A CompareAndSwap(state, 0, 2) is true) – Whiteclaws Jun 05 '17 at 22:51
  • I cannot imagine that the other threads will only ever react if state is 0. And "trash" means trash for the purpose of setting it finally to 0. The trash for this goal can move through other valid states, which are trash compared to the intended 0, but cannot be distinguished from other valid values. e.g. Valid values 0,1,2,3. Clear the 3 in two steps, you either get a valid non-zero-trash "2" or "1" in the middle of the operation. – Yunnosch Jun 05 '17 at 22:54
  • @Whiteclaws More generically speaking, thinking through all possible combinations of concurrent access is a valid protection mechanism. It is however extremely coslty in many ways (design effort, test effort, risk during maintenance...). Only if those costs are in total smaller than the intended saving (possibly performance), it is feasible to go that way, instead of using an appropriate protection mechanism. – Yunnosch Jun 05 '17 at 22:58
  • I assume that only debugging will tell if this works or not, Thank you for your great answers! – Whiteclaws Jun 05 '17 at 23:03
  • My pleasure. Debugging would be like testing and testing never can prove absence of problems, be careful not to be fooled. I have a mantra at work "Frequent errors are better than rare errors; they are found during testing. Therefor never make a time window smaller, make it bigger or close it." – Yunnosch Jun 05 '17 at 23:06