On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeod <amacl...@redhat.com> wrote: >> Hi, >> >> On Tue, 13 Sep 2011, Andrew MacLeod wrote: >> >>> Your example was not about regular stores, it used atomic variables. >> >> This reads as if there exists non-atomic variables in the new C++ >> mem-model. Assuming that this is so, why do those ugly requirements of >> not introducing new data races also apply to those non-atomic datas? >> >> > Why is it ugly to avoid introducing a data race into a race-free program? I > would think that is a basic necessity for a multi threaded program. > > There are normal everyday shared variables like we've always had, and there > are the new atomic variables which have slightly different characteristics. > > The C++11 memory model asserts that a program containing data races > involving *non-atomic* variables has undefined semantics. The compiler is > not allowed to introduce any data races into an otherwise correct program.
C++11 specifies data races in terms of properties of the source code. A conforming implementation may translate that code into something that races on actual hardware if the race is benign _on that hardware_. For example, it might read from a memory address that's being written to concurrently if it knows that the write cannot materially affect the value read. A user's C++ code that attempted to do so would have undefined behavior, but the C++ compiler is generating code for some more concrete platform that will likely have a range of possible behaviors for such races. Of course on a platform that actually diagnosed concurrent accesses such games would be disallowed, and we'd be back to a land in which the C++ compiler really could not introduce races unless they already existed in the user's code. -- James
