From: Dmitry Vyukov <dvyukov@google.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
libstdc++@gcc.gnu.org, Alexander Potapenko <glider@google.com>,
Kostya Serebryany <kcc@google.com>,
Torvald Riegel <triegel@redhat.com>
Subject: Re: [Patch, libstdc++] Fix data races in basic_string implementation
Date: Tue, 01 Sep 2015 15:42:00 -0000 [thread overview]
Message-ID: <CACT4Y+b5rPevB7foQqmvu+PyZP=wSQ+vCWY7YbKgj3OoUFKmgA@mail.gmail.com> (raw)
In-Reply-To: <20150901150847.GH2631@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 01/09/15 16:56 +0200, Dmitry Vyukov wrote:
>>
>> I don't understand how a new gcc may not support __atomic builtins on
>> ints. How it is even possible? That's a portable API provided by
>> recent gcc's...
>
>
> The built-in function is always defined, but it might expand to a call
> to an external function in libatomic, and it would be a regression for
> code using std::string to start requiring libatomic (although maybe it
> would be necessary if it's the only way to make the code correct).
>
> I don't know if there are any targets that define __GTHREADS and also
> don't support __atomic_load(int*, ...) without libatomic. If such
> targets exist then adding a new configure check that only depends on
> __atomic_load(int*, ...) would mean we keep supporting those targets.
>
> Another option would be to simply do:
>
> bool
> _M_is_shared() const _GLIBCXX_NOEXCEPT
> #if defined(__GTHREADS)
> + { return __atomic_load(&this->_M_refcount, __ATOMIC_ACQUIRE) > 0; }
> +#else
> { return this->_M_refcount > 0; }
> +#endif
>
> and see if anyone complains!
I like this option!
If a platform uses multithreading and has non-inlined atomic loads,
then the way to fix this is to provide inlined atomic loads rather
than to fix all call sites.
Attaching new patch. Please take another look.
[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 1449 bytes --]
Index: include/bits/basic_string.h
===================================================================
--- include/bits/basic_string.h (revision 227363)
+++ include/bits/basic_string.h (working copy)
@@ -2601,11 +2601,32 @@
bool
_M_is_leaked() const _GLIBCXX_NOEXCEPT
- { return this->_M_refcount < 0; }
+ {
+#if defined(__GTHREADS)
+ // _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
+ // so we need to use an atomic load. However, _M_is_leaked
+ // predicate does not change concurrently (i.e. the string is either
+ // leaked or not), so a relaxed load is enough.
+ return __atomic_load_n(&this->_M_refcount, __ATOMIC_RELAXED) < 0;
+#else
+ return this->_M_refcount < 0;
+#endif
+ }
bool
_M_is_shared() const _GLIBCXX_NOEXCEPT
- { return this->_M_refcount > 0; }
+ {
+#if defined(__GTHREADS)
+ // _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
+ // so we need to use an atomic load. Another thread can drop last
+ // but one reference concurrently with this check, so we need this
+ // load to be acquire to synchronize with release fetch_and_add in
+ // _M_dispose.
+ return __atomic_load_n(&this->_M_refcount, __ATOMIC_ACQUIRE) > 0;
+#else
+ return this->_M_refcount > 0;
+#endif
+ }
void
_M_set_leaked() _GLIBCXX_NOEXCEPT
next prev parent reply other threads:[~2015-09-01 15:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 12:52 Dmitry Vyukov
2015-09-01 14:27 ` Jonathan Wakely
2015-09-01 14:56 ` Dmitry Vyukov
2015-09-01 15:08 ` Jonathan Wakely
2015-09-01 15:42 ` Dmitry Vyukov [this message]
2015-09-02 13:17 ` Jonathan Wakely
2015-09-02 14:02 ` Dmitry Vyukov
2015-09-02 14:08 ` Jonathan Wakely
2015-09-02 14:39 ` Dmitry Vyukov
2015-09-02 10:58 ` Marc Glisse
2015-09-02 13:50 ` Dmitry Vyukov
2015-09-02 14:05 ` Jonathan Wakely
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='CACT4Y+b5rPevB7foQqmvu+PyZP=wSQ+vCWY7YbKgj3OoUFKmgA@mail.gmail.com' \
--to=dvyukov@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=glider@google.com \
--cc=jwakely@redhat.com \
--cc=kcc@google.com \
--cc=libstdc++@gcc.gnu.org \
--cc=triegel@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).