From: Michael Matz <matz@suse.de>
To: Andrew MacLeod <amacleod@redhat.com>
Cc: Miles Bader <miles@gnu.org>, gcc@gcc.gnu.org
Subject: Re: C++0x Memory model and gcc
Date: Mon, 17 May 2010 13:12:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1005171507410.1097@wotan.suse.de> (raw)
In-Reply-To: <4BEAA8DA.9080904@redhat.com>
Hi,
On Wed, 12 May 2010, Andrew MacLeod wrote:
> 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.
Are you and the other proponents of that memory model seriously proposing
it as an alternative to explicit locking via atomic builtins (that map to
some form of atomic instructions)?
Ciao,
Michael.
next prev parent reply other threads:[~2010-05-17 13:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-08 14:38 Jean-Marc Bourguet
2010-05-08 20:18 ` Albert Cohen
2010-05-10 4:40 ` Ian Lance Taylor
2010-05-10 17:23 ` Andrew MacLeod
2010-05-11 6:20 ` Miles Bader
2010-05-11 12:49 ` Andrew MacLeod
2010-05-12 5:21 ` Miles Bader
2010-05-12 13:10 ` Andrew MacLeod
2010-05-17 13:12 ` Michael Matz [this message]
2010-05-17 14:05 ` Ian Lance Taylor
2010-05-17 14:24 ` Michael Matz
2010-05-17 20:22 ` Ian Lance Taylor
2010-05-17 14:09 ` Andrew MacLeod
2010-05-17 14:55 ` Michael Matz
2010-05-17 16:36 ` Andrew MacLeod
-- strict thread matches above, loose matches on Subject: below --
2010-05-06 15:43 Andrew MacLeod
2010-05-06 15:51 ` Richard Guenther
2010-05-06 16:11 ` Richard Guenther
2010-05-06 16:23 ` Andrew MacLeod
2010-05-07 9:15 ` Richard Guenther
2010-05-07 13:27 ` Andrew MacLeod
2010-05-07 14:26 ` Ian Lance Taylor
2010-05-06 15:54 ` Joseph S. Myers
2010-05-06 16:12 ` Andrew MacLeod
2010-05-06 20:40 ` Ian Lance Taylor
2010-05-06 22:02 ` Andrew MacLeod
2010-05-07 13:55 ` Mark Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1005171507410.1097@wotan.suse.de \
--to=matz@suse.de \
--cc=amacleod@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=miles@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).