5 ms·

> However if the bug is a one in a million This is what RR is for: you only need to be able to reproduce the bug once inside RR. > ensures some places where i

by nullc 7y ago

> However if the bug is a one in a million This is what RR is for: you only need to be able to reproduce the bug once inside RR. > ensures some places where it looks like a race are actually not Uh be careful, if you're writing in a high level language... such as C: there are no safe data races. https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong https://software.intel.com/en-us/blogs/2013/01/06/benign-dat... The compiler is free to reorder operations in ways that make what appears to be a safe data race unsafe.

bluGill 7y ago
There are limits you can place on the compiler. There are atomics in the compiler. There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. There are times where you know the other thread isn't started yet. There are platform specific ways to flush all the caches long after the race in question which can be tied to something else that is synchronized across threads...
- saagarjha 7y ago
  > There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. Often it is difficult to prove this to the compiler.
  - bluGill 7y ago
    I don't need to prove it to the compiler. I can prove it by a higher level understanding of my own system. So long as the compiler emits the memory barrier when I need it to, and the other thread stays in the state where it won't be reading the memory in question it doesn't matter what the compiler knows.
Skunkleton 7y ago
>The compiler is free to reorder operations in ways that make what appears to be a safe data race unsafe. So is the CPU.
- ajross 7y ago
  Only as documented by the architecture. Memory order can be affirmatively proven by reading assembly as long as you know the rules.
  - deleted 7y ago
    [deleted]
  - Skunkleton 7y ago
    How do you mean? On x86 even if you have the assembly, you don’t know what order loads and stores will execute in. Depending on the architecture there will be some constraints, but usually not enough to guarantee a particular order. That is why barriers exist.
    - saagarjha 7y ago
      On x86_64 this is the only kind of reordering that is allowed; there are other things that presented in a way that guarantees apparent order.
    - ajross 7y ago
      Memory barriers (also cache control mechanisms) are documented by the architecture, and are exposed as instructions or similar hardware interfaces. Obviously OO execution exists, but it's not a magical insurmountable fence (see what I did there?) that blocks all optimization. It has well-specified rules on every architecture. If it didn't, concurrent code couldn't be written correctly at all. And on x86, the rules amount to "the processor will expend herculean effort to make sure that all memory orderings look identical to all readers in the system" (with a few oddball exceptions, read the SDM, yada yada). Really, on x86 you pretty much don't have to worry about this. If two memory operations happen in a given sequence in the disassembly, literally everyone who reads those locations will agree they happened in the order presented, no matter what optimizations the hardware might have done internally.
ajross 7y ago
No real world compiler exists for that regime that doesn't provide appropriate control over memory ordering. But yes, the problem is difficult and you have to use those features.

by nullc 7y ago

bluGill 7y ago

There are limits you can place on the compiler. There are atomics in the compiler. There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. There are times where you know the other thread isn't started yet. There are platform specific ways to flush all the caches long after the race in question which can be tied to something else that is synchronized across threads...

saagarjha 7y ago
> There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. Often it is difficult to prove this to the compiler.
- bluGill 7y ago
  I don't need to prove it to the compiler. I can prove it by a higher level understanding of my own system. So long as the compiler emits the memory barrier when I need it to, and the other thread stays in the state where it won't be reading the memory in question it doesn't matter what the compiler knows.

Skunkleton 7y ago

>The compiler is free to reorder operations in ways that make what appears to be a safe data race unsafe. So is the CPU.

ajross 7y ago
Only as documented by the architecture. Memory order can be affirmatively proven by reading assembly as long as you know the rules.
- deleted 7y ago
  [deleted]
- Skunkleton 7y ago
  How do you mean? On x86 even if you have the assembly, you don’t know what order loads and stores will execute in. Depending on the architecture there will be some constraints, but usually not enough to guarantee a particular order. That is why barriers exist.
  - saagarjha 7y ago
    On x86_64 this is the only kind of reordering that is allowed; there are other things that presented in a way that guarantees apparent order.
  - ajross 7y ago
    Memory barriers (also cache control mechanisms) are documented by the architecture, and are exposed as instructions or similar hardware interfaces. Obviously OO execution exists, but it's not a magical insurmountable fence (see what I did there?) that blocks all optimization. It has well-specified rules on every architecture. If it didn't, concurrent code couldn't be written correctly at all. And on x86, the rules amount to "the processor will expend herculean effort to make sure that all memory orderings look identical to all readers in the system" (with a few oddball exceptions, read the SDM, yada yada). Really, on x86 you pretty much don't have to worry about this. If two memory operations happen in a given sequence in the disassembly, literally everyone who reads those locations will agree they happened in the order presented, no matter what optimizations the hardware might have done internally.

ajross 7y ago

No real world compiler exists for that regime that doesn't provide appropriate control over memory ordering. But yes, the problem is difficult and you have to use those features.