Miles Bader wrote:
Andrew MacLeod <amacl...@redhat.com> writes:
-fmemory-model=single     - Enable all data races introductions, as they
are today. (relax all 4 internal restrictions.)
One could still use this mode with a multi-threaded program as long as
explicit synchronization is done, right?
Right.  Its just a single processor memory model, so it doesn't limit
any optimizations.

Hmm, though now that I think about it, I'm not exactly sure what I mean
by "explicit synchronization".  Standard libraries (boost threads, the
upcoming std::thread) provide things like mutexes and
conditional-variables, but does using those guarantee that the right
things happen with any shared data-structures they're used to
coordinate...?


Well, you get the same thing you get today. Any synchronization done via a function call will tend to be correct since we never move shared memory operations across calls. Depending on your application, the types of data races the options deal with may not be an issue. Using the options will eliminate having to think whether they are issues or not at a (hopefully) small cost.

Since the atomic operations are being built into the compiler, the intent is to eventually optimize and inline them for speed... and in the best case, simply result in a load or store. That's further work of course, but these options are laying some of the groundwork.

Andrew

Reply via email to