6 ms·

From the article: >>>The Problem: Even if the reader detects that the data was modified and discards the copy before use, the act of copying the non-atomic data

From the article: >>>The Problem: Even if the reader detects that the data was modified and discards the copy before use, the act of copying the non-atomic data itself still triggers undefined behavior. While a sequence lock can detect that a data race occurred, it does not prevent it. Why is this a problem? Isn't the correct way to deal with a sequence lock failure to just retry? A torn read yes means you get undefined behavior as far as the result of your read, but you throw it all away and start again anyway so what is this solving?

charleslmunger 1mo ago
From a hardware perspective this is correct. From a language perspective it's UB, and unless your compiler has defined that UB, it doesn't matter what the hardware's behavior is unless you're writing assembly.
- jimaway123 1mo ago
  So you're saying the problem that this article is solving is just preventing the language from generating code that can possibly load some incorrect bytes from main memory, even though these incorrect bytes will in every case be ignored? Why is this considered a problem at all?
  - charleslmunger 1mo ago
    It's a problem for language specifiers, basically. The behavior is undefined in the standard; to rely on it you either need your implementation of the standard to define it themselves, or you need to bet that there is no possible sequence of machine instructions the compiler could emit that would implement the defined behavior in a way where a data race would do something harmful. As far as I know there is no reasonable compiler that wasn't specifically trying to add some kind of sanitizer that would emit anything other than plain memory reads, but it would be nice to not have to worry. But sanitizers are handy! I can imagine some sanitizer implementation forgoing extra internal synchronization that would only be needed in the case of program UB anyway.
adrian_b 1mo ago
The problem is that a reader should not do anything with the data that is read, which depends on its value, before validating the copy, by counter comparison. As another poster has said, the high-level languages leave undefined what happens when you copy non-atomically data that is written concurrently, but in fact the computer cannot catch fire when you do that, and the only thing that can happen is that the data may have values that are invalid for its type, e.g. an integer that is defined to belong in a range may have a value outside that range. A much more serious problem that is not mentioned in TFA is that on computers that do not use Intel/AMD CPUs, this algorithm needs write barriers and read barriers. The writer must use 2 write barriers, after incrementing the counter before accessing the shared data, and before incrementing the counter after finishing with the shared data. Similarly the reader needs read barriers after the first reading of the counter and before the final reading of the counter.
- jimaway123 1mo ago
  >>>The problem is that a reader should not do anything with the data that is read, which depends on its value, before validating the copy, by counter comparison. The description of the problem explicitly says that this is not happening. The data is being thrown away if the counter comparison fails. So the only undefined behavior that I can think they might be referring to is the act of loading the data itself, even though it is thrown away if it is wrong. Is that what they mean?

charleslmunger 1mo ago

From a hardware perspective this is correct. From a language perspective it's UB, and unless your compiler has defined that UB, it doesn't matter what the hardware's behavior is unless you're writing assembly.

jimaway123 1mo ago
So you're saying the problem that this article is solving is just preventing the language from generating code that can possibly load some incorrect bytes from main memory, even though these incorrect bytes will in every case be ignored? Why is this considered a problem at all?
- charleslmunger 1mo ago
  It's a problem for language specifiers, basically. The behavior is undefined in the standard; to rely on it you either need your implementation of the standard to define it themselves, or you need to bet that there is no possible sequence of machine instructions the compiler could emit that would implement the defined behavior in a way where a data race would do something harmful. As far as I know there is no reasonable compiler that wasn't specifically trying to add some kind of sanitizer that would emit anything other than plain memory reads, but it would be nice to not have to worry. But sanitizers are handy! I can imagine some sanitizer implementation forgoing extra internal synchronization that would only be needed in the case of program UB anyway.

adrian_b 1mo ago

The problem is that a reader should not do anything with the data that is read, which depends on its value, before validating the copy, by counter comparison. As another poster has said, the high-level languages leave undefined what happens when you copy non-atomically data that is written concurrently, but in fact the computer cannot catch fire when you do that, and the only thing that can happen is that the data may have values that are invalid for its type, e.g. an integer that is defined to belong in a range may have a value outside that range. A much more serious problem that is not mentioned in TFA is that on computers that do not use Intel/AMD CPUs, this algorithm needs write barriers and read barriers. The writer must use 2 write barriers, after incrementing the counter before accessing the shared data, and before incrementing the counter after finishing with the shared data. Similarly the reader needs read barriers after the first reading of the counter and before the final reading of the counter.

jimaway123 1mo ago
>>>The problem is that a reader should not do anything with the data that is read, which depends on its value, before validating the copy, by counter comparison. The description of the problem explicitly says that this is not happening. The data is being thrown away if the counter comparison fails. So the only undefined behavior that I can think they might be referring to is the act of loading the data itself, even though it is thrown away if it is wrong. Is that what they mean?