6 ms·

In other words, for Rust you'll need unsafe to exploit race conditions for performance optimisations.

by _nalply 6y ago

zozbot234 6y ago
Safe Rust only protects against data races (which imply memory unsafety, hence a "bug") not general race conditions.
- jfkebwjsbx 6y ago
  Data races don't imply memory unsafety (in the sense of having OOB accesses etc.). It is possible (and in rare cases, desirable) to have data races while still having a perfectly safe program.
  - ChrisSD 6y ago
    Could you explain that? Surely either it's dangerous to read and write simultaneously to a memory location or the operations are atomic (albeit perhaps unordered) and thus there is no data race?
    - zozbot234 6y ago
      Well, your memory model might fail to properly expose "atomic" access at the level you're actually relying on to prove that your 'data race' is safe. (Or using such fine-grained atomic accesses might have bad performance implications that can't be worked around using relaxed operations, etc.) But I don't think that's going to be a common case.
      - ChrisSD 6y ago
        But any optimizing compiler is surely going to assume its memory model is adhered to, no? Therefore any "data races" will be undefined behaviour (even if they're atomic on physical hardware).
        jfkebwjsbx 6y ago
        "Any" and "surely" are very strong words! Compilers implement different kinds of languages, guarantees, extensions and what not. Even if your program is not conforming to whatever standard, it may be very well be useful and working in most compilers out there. As an example, Linux is not conforming C, including triggering UB. But at least two major compilers support the intended semantics even if they are forbidden by the standard.
        ChrisSD 6y ago
        UB is UB. It might work. It might work now but not in the future. It might work in some situation but not others. It might appear to work but introduce subtle bugs elsewhere in the program. Linux, as Linus has said, isn't written in ISO C it's written (or was) in GNU C. The two had something of a symbiotic relationship for a long time. Which is why porting it to LLVM was such a tremendous effort. Which is to say, Linux conforms to the memory model of the compilers it compiles on (or vice versa). Not ISO C's memory model. So I'm not sure how your example is relevant.
        steerablesafe 6y ago
        Linux arguably relies on compiler extensions. Compilers are allowed to define behavior that is undefined by the language standards, effectively extending the language.
        gpderetta 6y ago
        There has been a significant push to get Linux to use the c11 conformant gcc builtins. There has been significant push back though, but at least some bits have been updated.
    - jfkebwjsbx 6y ago
      No, it is not "dangerous". CPUs are designed to deal with that all the time (it is a whole field of research) and give you different guarantees when it does happen. If your software is designed with that in mind, then a data race is not a bug.
      - ChrisSD 6y ago
        I'm not sure I understand you. If it's not dangerous and there are guarantees then there isn't a data race to begin with.
  - gpderetta 6y ago
    at least in C and C++ data races are UB by defintion.
  - fluffything 6y ago
    >Data races don't imply memory unsafety (in the sense of having OOB accesses etc.). Data races are undefined behavior on all major programming languages (C, C++, Rust, Java, Go, Swift, ...) and all major compilers compile code under the assumption that they do not happen. If your program has a data-race, neither the language specification nor the compiler make any guarantees about the behavior of such programs. Needles to say, this is neither safe, nor desirable, nor doing so produces perfectly safe programs. The idea that data-races are safe because the load and store memory instructions that the CPU has are atomic is completely flawed, because it ignores the fact that the CPU does not execute the program you wrote, but the machine code that the compiler generates, and the compiler can and will reorganize non-atomic loads and stores under the assumption that they don't need to be atomic. If your program has a data-race, the compiler provides no guarantees. It does not guarantee that the binary will reach the location where the data race happens. It does not even guarantee that the binary produced will be an executable binary, or that it will produce a binary at all (e.g. it does not guarantee that compilation terminates successfully).
CodesInChaos 6y ago
No. * Data races using normal memory access function are impossible in safe code, and undefined behaviour in unsafe code. So unsafe code attempting this is incorrect. * Data races using atomic types are possible in safe code. Some of the setup code might be unsafe internally while presenting a safe API (e.g. creating shared memory and giving you an `&[AtomicU8]` to that memory). * Other race conditions (mostly non-deterministic order of lock acquisition) are also possible in safe code. The typical example of this is that writing to the console from multiple threads uses locks on individual write calls, which prevents torn writes but the order of those write outputs in non deterministic.

In other words, for Rust you'll need unsafe to exploit race conditions for performance optimisations.

zozbot234 6y ago

Safe Rust only protects against data races (which imply memory unsafety, hence a "bug") not general race conditions.

jfkebwjsbx 6y ago
Data races don't imply memory unsafety (in the sense of having OOB accesses etc.). It is possible (and in rare cases, desirable) to have data races while still having a perfectly safe program.
- ChrisSD 6y ago
  Could you explain that? Surely either it's dangerous to read and write simultaneously to a memory location or the operations are atomic (albeit perhaps unordered) and thus there is no data race?
  - zozbot234 6y ago
    Well, your memory model might fail to properly expose "atomic" access at the level you're actually relying on to prove that your 'data race' is safe. (Or using such fine-grained atomic accesses might have bad performance implications that can't be worked around using relaxed operations, etc.) But I don't think that's going to be a common case.
    - ChrisSD 6y ago
      But any optimizing compiler is surely going to assume its memory model is adhered to, no? Therefore any "data races" will be undefined behaviour (even if they're atomic on physical hardware).
      - jfkebwjsbx 6y ago
        "Any" and "surely" are very strong words! Compilers implement different kinds of languages, guarantees, extensions and what not. Even if your program is not conforming to whatever standard, it may be very well be useful and working in most compilers out there. As an example, Linux is not conforming C, including triggering UB. But at least two major compilers support the intended semantics even if they are forbidden by the standard.
        ChrisSD 6y ago
        UB is UB. It might work. It might work now but not in the future. It might work in some situation but not others. It might appear to work but introduce subtle bugs elsewhere in the program. Linux, as Linus has said, isn't written in ISO C it's written (or was) in GNU C. The two had something of a symbiotic relationship for a long time. Which is why porting it to LLVM was such a tremendous effort. Which is to say, Linux conforms to the memory model of the compilers it compiles on (or vice versa). Not ISO C's memory model. So I'm not sure how your example is relevant.
        steerablesafe 6y ago
        Linux arguably relies on compiler extensions. Compilers are allowed to define behavior that is undefined by the language standards, effectively extending the language.
        gpderetta 6y ago
        There has been a significant push to get Linux to use the c11 conformant gcc builtins. There has been significant push back though, but at least some bits have been updated.
  - jfkebwjsbx 6y ago
    No, it is not "dangerous". CPUs are designed to deal with that all the time (it is a whole field of research) and give you different guarantees when it does happen. If your software is designed with that in mind, then a data race is not a bug.
    - ChrisSD 6y ago
      I'm not sure I understand you. If it's not dangerous and there are guarantees then there isn't a data race to begin with.
- gpderetta 6y ago
  at least in C and C++ data races are UB by defintion.
- fluffything 6y ago
  >Data races don't imply memory unsafety (in the sense of having OOB accesses etc.). Data races are undefined behavior on all major programming languages (C, C++, Rust, Java, Go, Swift, ...) and all major compilers compile code under the assumption that they do not happen. If your program has a data-race, neither the language specification nor the compiler make any guarantees about the behavior of such programs. Needles to say, this is neither safe, nor desirable, nor doing so produces perfectly safe programs. The idea that data-races are safe because the load and store memory instructions that the CPU has are atomic is completely flawed, because it ignores the fact that the CPU does not execute the program you wrote, but the machine code that the compiler generates, and the compiler can and will reorganize non-atomic loads and stores under the assumption that they don't need to be atomic. If your program has a data-race, the compiler provides no guarantees. It does not guarantee that the binary will reach the location where the data race happens. It does not even guarantee that the binary produced will be an executable binary, or that it will produce a binary at all (e.g. it does not guarantee that compilation terminates successfully).

CodesInChaos 6y ago

No. * Data races using normal memory access function are impossible in safe code, and undefined behaviour in unsafe code. So unsafe code attempting this is incorrect. * Data races using atomic types are possible in safe code. Some of the setup code might be unsafe internally while presenting a safe API (e.g. creating shared memory and giving you an `&[AtomicU8]` to that memory). * Other race conditions (mostly non-deterministic order of lock acquisition) are also possible in safe code. The typical example of this is that writing to the console from multiple threads uses locks on individual write calls, which prevents torn writes but the order of those write outputs in non deterministic.