From: Andrew MacLeod <amacleod@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>,
hp@axis.com, gcc-patches@gcc.gnu.org,
libstdc++@gcc.gnu.org, Benjamin Kosnik <bkoz@redhat.com>,
Richard Henderson <rth@redhat.com>
Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3
Date: Mon, 07 Nov 2011 17:24:00 -0000 [thread overview]
Message-ID: <4EB81145.9090804@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1111071621160.24579@digraph.polyomino.org.uk>
On 11/07/2011 11:24 AM, Joseph S. Myers wrote:
> On Mon, 7 Nov 2011, Andrew MacLeod wrote:
>
>> Actually, this target has no lock free support whatsoever? ie, no
>> compare_and_swap instruction, nor an implementation of sync_lock_test_and_set
>> and sync_lock_release?
>>
>> I think the libstdc++ standard now requires the class atomic_flag to be lock
>> free in order to conform (n3242 29.7.2)
>>
>> So I guess this is the situation which all the atomic tests are not even
>> suppose to be run since they aren't supported. My guess is that in the
>> previous releases the c++ header files probably provided a locked
>> implementation of test_and_set, and so the tests would run.
> For bare-metal targets there should maybe be an option to presume there is
> just one thread and map all atomic operations to dumb non-atomic versions,
> which is perfectly valid in such a case. But that's a new feature; we
> didn't have it for __sync_* either.
>
Hmm. actually, there is a proposed option flag which I noticed never got
implemented when I was looking back through stuff on the weekend:
http://gcc.gnu.org/wiki/Atomic/GCCMM/ExecutiveSummary
Exposure to the normal users can be provided through something along the
lines of:
-fmemory-model=c++0x - Disable data races as per architectural requirements.
-fmemory-model=safe - Disable all data race introductions. (enforce all
4 internal restrictions.)
-fmemory-model=single - Enable all data races introductions, as they are
today. (relax all 4 internal restrictions.)
we could do that with -fmemory-model=single and it would be pretty
natural...and easy. The just fall back to a load for test and set and
then atomic_flag would work fine. Such targets would make that the
default, and since the option isn't set to C++11, it wouldn't have to be
conforming anyway.
Mostly I think it the option wasn't implemented because we never
finished up with the load/store data race work.
We continue to count on __sync_test_and_set and sync_lock_release for
targets without a compare and swap operation to provide the atomic_flag
implementation.
As for all the rest of the atomics, it defined right now that if the
compiler cannot generate lock free instructions, it generates a call to
the external library. I would suggest on such a limited target that
they build the library, and it would provide locked routines for all the
rest of the external calls. The library could also be configured for
single thread operation which would then just provide the operation
without locks if desired.
A buildable library is forthcoming in the next few months.
Andrew
next prev parent reply other threads:[~2011-11-07 17:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-03 23:52 Andrew MacLeod
2011-11-04 18:17 ` Jeff Law
2011-11-04 18:53 ` Andrew MacLeod
2011-11-07 0:54 ` Hans-Peter Nilsson
2011-11-07 4:48 ` Andrew MacLeod
2011-11-07 11:36 ` Hans-Peter Nilsson
2011-11-07 14:41 ` Andrew MacLeod
2011-11-07 14:56 ` Andrew MacLeod
2011-11-07 15:38 ` Hans-Peter Nilsson
2011-11-07 16:28 ` Joseph S. Myers
2011-11-07 17:24 ` Andrew MacLeod [this message]
2011-11-07 17:43 ` Hans-Peter Nilsson
2011-11-07 18:27 ` Andrew MacLeod
2011-11-08 6:45 ` Hans-Peter Nilsson
2011-11-08 13:43 ` Andrew MacLeod
2011-11-11 17:49 ` Benjamin Kosnik
2011-11-11 17:56 ` Andrew MacLeod
2011-11-11 21:07 ` Hans-Peter Nilsson
2011-11-11 23:34 ` Torvald Riegel
2011-11-11 20:27 ` Hans-Peter Nilsson
2011-11-07 16:32 ` Richard Henderson
2011-11-08 20:22 ` Hans-Peter Nilsson
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=4EB81145.9090804@redhat.com \
--to=amacleod@redhat.com \
--cc=bkoz@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hans-peter.nilsson@axis.com \
--cc=hp@axis.com \
--cc=joseph@codesourcery.com \
--cc=libstdc++@gcc.gnu.org \
--cc=rth@redhat.com \
/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).