Simon: yes, I tend to think that a stream like interface for communicating between threads is the most workable method for multi-multi-core systems. That idea came up earlier also.

The question is: can this be fixed without imposing undue overhead?

If writes to shared variables should be visible in-order, the implementation would have to insert memory barriers, which is an OS-specific thing (so the compiler would have to be OS aware). If it were to do this implicitly, it’d have to guess and err on the side of caution, degrading performance. If the programmer had to insert the barriers, there is no gain compared to the status quo.

Shared memory between threads seems to be a bad idea altogether. I wonder if it would make more sense to have a “stream” like interface that an implementation could map to shared memory if it could guarantee consistency, but were not required to if other methods made more sense (for example, for NUMA).

volatile doesn’t help all that much. In particular, if you have two volatile global variables, and one thread changes first A and then B, there is no guarantee that a thread running on a different core will see the changes in that order. It might very sell see the change to B before it sees the change to A. volatile only applies within a single thread, it does not imply anything about threads running on multiple cores.

When I write multi-threaded programs, rather than thinking of a single abstract machine with multiple threads, I think of multiple abstract machines that can see exactly each other’s “observable behaviour”, which is well-defined in the standard, and nothing else.

Guaranteed atomic types were something I sorely missed in the standard — I just assumed that “unsigned int” was atomic for all purposes, which I believe holds true in most if not all implementations. My only use for them, however, is reporting progress when one thread is handling I/O and the other is doing a lengthy computation.

The new standard essentially codifies existing practice in treating everything like I/O buffers (i.e. accesses aren’t ordered, but are guaranteed to happen) unless told otherwise. Since the overwhelming majority of objects in my programs aren’t shared, I’d actually prefer explicitly marking those that are (that takes quite a few load/store instructions out of the hot path), however that would break lots of existing code.