3 ms·

I agree that this sounds more like "volatile", but it still makes sense that programmers should be able to rely on atomic operations for inter-thread communicat

by yalue 10y ago

I agree that this sounds more like "volatile", but it still makes sense that programmers should be able to rely on atomic operations for inter-thread communication. According to the comments on the bug report, this behavior is inspired by C++'s <atomic> library, which guarantees cross-thread visibility.

deleted 10y ago
[deleted]
chimeracoder 10y ago
> I agree that this sounds more like "volatile", but it still makes sense that programmers should be able to rely on atomic operations for inter-thread communication. Only in the sense that they won't see inconsistent (intermediate) states. Atomicity shouldn't guarantee order per se - if you want both, you need a mutex.
- gpderetta 10y ago
  Ordered atomic operations like C++ std::atomic or java/C# volatile do guarantee some ordering. For example if one thread modifies an object and then stores a pointer to an atomic variable, under default visibility rules, another thread reading that pointer from the atomic variable is guaranteed to see the modifications to the object itself, i.e. the update, the store and the remote load are ordered. It is possible to have a model where all atomic operations are relaxed (i.e. unordered) and use explicit barriers for ordering (which is closer to how some, but not all, CPUs work), but it is significantly harder to reason about and prove algorithms correct under it. edit: wording
  - wbl 10y ago
    No. Read the spec. There is no deadline for atomics to be visible. What is true is that some operations have happens-before ordering, and if a store happens-before a load, the load will see the result of the store.
    - gpderetta 10y ago
      Did you reply to the wrong post? My post was only about ordering. Still the C++ spec has wording about making stores visible in a reasonable time. The wording is non-normative as they run out of time (ah!) while trying to come up with a more formal (and implementable) specification. edit: oh, I see I wrote 'default visibility' instead of 'default ordering'.

by yalue 10y ago

deleted 10y ago

[deleted]

chimeracoder 10y ago

> I agree that this sounds more like "volatile", but it still makes sense that programmers should be able to rely on atomic operations for inter-thread communication. Only in the sense that they won't see inconsistent (intermediate) states. Atomicity shouldn't guarantee order per se - if you want both, you need a mutex.

gpderetta 10y ago
Ordered atomic operations like C++ std::atomic or java/C# volatile do guarantee some ordering. For example if one thread modifies an object and then stores a pointer to an atomic variable, under default visibility rules, another thread reading that pointer from the atomic variable is guaranteed to see the modifications to the object itself, i.e. the update, the store and the remote load are ordered. It is possible to have a model where all atomic operations are relaxed (i.e. unordered) and use explicit barriers for ordering (which is closer to how some, but not all, CPUs work), but it is significantly harder to reason about and prove algorithms correct under it. edit: wording
- wbl 10y ago
  No. Read the spec. There is no deadline for atomics to be visible. What is true is that some operations have happens-before ordering, and if a store happens-before a load, the load will see the result of the store.
  - gpderetta 10y ago
    Did you reply to the wrong post? My post was only about ordering. Still the C++ spec has wording about making stores visible in a reasonable time. The wording is non-normative as they run out of time (ah!) while trying to come up with a more formal (and implementable) specification. edit: oh, I see I wrote 'default visibility' instead of 'default ordering'.