4 ms·

The difficulty with "benign" data races and atomic operations with weak ordering, is that they're not guaranteed to behave like the target architecture behaves!

by pornel 6y ago

The difficulty with "benign" data races and atomic operations with weak ordering, is that they're not guaranteed to behave like the target architecture behaves! It's insufficient to say "this is fine on x86" even in an x86-only program! That's because the optimizer symbolically executes the program according to the C memory model, not x86 memory model (as if it was some kind of Low-Level Virtual Machine…). The optimizer may reorder or remove memory accesses in ways that wouldn't happen on the target hardware.

jackewiehose 6y ago
> The optimizer may reorder or remove memory accesses in ways that wouldn't happen on the target hardware. yes, but so far (C/C++2003) I always thought that something like mutex.lock() in the example, before accessing x, would be recognized as a memory barrier by the optimizer so it should be safe to access x as long as your thread acquired the lock. Now for C++11 I'm not so sure anymore because of this last paragraph of the article: > What’s more, since C++11 has well defined memory semantics, compiler writers are no longer forced to be conservative with their optimizations. If the programmer doesn’t specifically mark shared variables as atomic, the compiler is free to optimize code as if it were single-threaded. Does this really mean that the above x must always be declared volatile even though it's surrounded by a mutex-lock? If so I hope there's a compiler flag do get the old behavior...
- secondcoming 6y ago
  In this instance the shared variable isn't x, but the internal workings of the mutex.
- manwe150 6y ago
  A mutex lock will still be modeled as an aliasing read/write of all global memory. So you’re fine.
- kccqzy 6y ago
  No, you shouldn't declare x as volatile. Also note that the article never even talked about volatile in C++; volatile in C++ is entirely different from volatile in Java. Instead when you use a mutex, your mutex internally uses atomics. In fact the simplest kind of mutex can be built with atomics alone (spinlock), though a production-quality mutex will have to use other techniques such as a Linux futex.
userbinator 6y ago
That's because the optimizer symbolically executes the program according to the C memory model, not x86 memory model ...and I think that is a huge problem, because it strays from the spirit of the language in that it's supposed to be "closer to the hardware" than other HLLs. Edit: care to give a counterargument?
- a1369209993 6y ago
  Exactly this. Undefined behaviour exists for the purpose of portability, not optimization; actively going out of it's way to abuse it is a compiler bug.
- pornel 6y ago
  Optimizers follow what the C specification says. When C says "this can be reordered", then they can reorder. There are practical reasons why it's not "closer to the hardware": • it would be harder to have a single compiler front-end for multiple CPU back-ends. • what programmers have in mind for "closer to the hardware" is actually quite fuzzy, based roughly on how they imagine a naive C compiler would generate machine code. That interpretation doesn't have a spec. The things that seem obvious aren't that obvious in detail, or lead to unexpected performance cliffs (e.g. did you know that non-byte array indexing on 64-bit machines would be slow if signed int was defined to "simply" overflow?)
- ganafagol 6y ago
  I'm not the one who downvoted you, but the counterargument is that such a target-specific approach prevents any reasonable effort to consistently define the semantics of any programming language. "On x86_amd_this_and_that processor the program means this, on arm_64_some_version it means that and on x86_intel_something again something else". This would not just be hell, it would be unworkable. In other words, any approach other than an abstract machine model is doomed. Ideally this abstract machine is rather close to real world machines, but it can't be identical to all of them, nor is it reasonable to start special casing.
  - userbinator 6y ago

by pornel 6y ago

jackewiehose 6y ago

> The optimizer may reorder or remove memory accesses in ways that wouldn't happen on the target hardware. yes, but so far (C/C++2003) I always thought that something like mutex.lock() in the example, before accessing x, would be recognized as a memory barrier by the optimizer so it should be safe to access x as long as your thread acquired the lock. Now for C++11 I'm not so sure anymore because of this last paragraph of the article: > What’s more, since C++11 has well defined memory semantics, compiler writers are no longer forced to be conservative with their optimizations. If the programmer doesn’t specifically mark shared variables as atomic, the compiler is free to optimize code as if it were single-threaded. Does this really mean that the above x must always be declared volatile even though it's surrounded by a mutex-lock? If so I hope there's a compiler flag do get the old behavior...

secondcoming 6y ago
In this instance the shared variable isn't x, but the internal workings of the mutex.
manwe150 6y ago
A mutex lock will still be modeled as an aliasing read/write of all global memory. So you’re fine.
kccqzy 6y ago
No, you shouldn't declare x as volatile. Also note that the article never even talked about volatile in C++; volatile in C++ is entirely different from volatile in Java. Instead when you use a mutex, your mutex internally uses atomics. In fact the simplest kind of mutex can be built with atomics alone (spinlock), though a production-quality mutex will have to use other techniques such as a Linux futex.

userbinator 6y ago

That's because the optimizer symbolically executes the program according to the C memory model, not x86 memory model ...and I think that is a huge problem, because it strays from the spirit of the language in that it's supposed to be "closer to the hardware" than other HLLs. Edit: care to give a counterargument?

a1369209993 6y ago
Exactly this. Undefined behaviour exists for the purpose of portability, not optimization; actively going out of it's way to abuse it is a compiler bug.
pornel 6y ago
Optimizers follow what the C specification says. When C says "this can be reordered", then they can reorder. There are practical reasons why it's not "closer to the hardware": • it would be harder to have a single compiler front-end for multiple CPU back-ends. • what programmers have in mind for "closer to the hardware" is actually quite fuzzy, based roughly on how they imagine a naive C compiler would generate machine code. That interpretation doesn't have a spec. The things that seem obvious aren't that obvious in detail, or lead to unexpected performance cliffs (e.g. did you know that non-byte array indexing on 64-bit machines would be slow if signed int was defined to "simply" overflow?)
ganafagol 6y ago
I'm not the one who downvoted you, but the counterargument is that such a target-specific approach prevents any reasonable effort to consistently define the semantics of any programming language. "On x86_amd_this_and_that processor the program means this, on arm_64_some_version it means that and on x86_intel_something again something else". This would not just be hell, it would be unworkable. In other words, any approach other than an abstract machine model is doomed. Ideally this abstract machine is rather close to real world machines, but it can't be identical to all of them, nor is it reasonable to start special casing.
- userbinator 6y ago