On Thu, Feb 4, 2021 at 7:46 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > How can we do that this is not a 1 byte flag this is enum so I don't > think we can read any atomic state without a spin lock here.
I think this discussion of atomics is confused. Let's talk about what atomic reads and writes mean. Imagine that you have a 64-bit value 0x0101010101010101. Somebody sets it to 0x0202020202020202. Imagine that just as they are doing that, someone else reads the value and gets 0x0202020201010101, because half of the value has been updated and the other half has not yet been updated yet. This kind of thing can actually happen on some platforms and what it means is that on those platforms 8-byte reads and writes are not atomic. The idea of an "atom" is that it can't be split into pieces but these reads and writes on some platforms are actually not "atomic" because they are split into two 4-byte pieces. But there's no such thing as a 1-byte read or write not being atomic. In theory you could imagine a computer where when you change 0x01 to 0x23 and read in the middle and see 0x21 or 0x13 or something, but no actual computers behave that way, or at least no mainstream ones that anybody cares about. So the idea that you somehow need a lock to prevent this is just wrong. Concurrent programs also suffer from another problem which is reordering of operations, which can happen either as the program is compiled or as the program is executed by the CPU. The CPU can see you set a->x = 1 and a->y = 2 and decide to update y first and then x even though you wrote it the other way around in the program text. To prevent this, we have barrier operations; see README.barrier in the source tree for a longer explanation. Atomic operations like compare-and-exchange are also full barriers, so that they not only prevent the torn read/write problem described above, but also enforce order of operations more strictly. Now I don't know whether a lock is needed here or not. Maybe it is; perhaps for consistency with other code, perhaps because the lock acquire and release is serving the function of a barrier; or perhaps to guard against some other hazard. But saying that it's because reading or writing a 1-byte value might not be atomic does not sound correct. -- Robert Haas EDB: http://www.enterprisedb.com
