public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Dmitry Vyukov <dvyukov@google.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: Wed, 02 Sep 2015 13:17:00 -0000	[thread overview]
Message-ID: <20150902131752.GJ2631@redhat.com> (raw)
In-Reply-To: <CACT4Y+b5rPevB7foQqmvu+PyZP=wSQ+vCWY7YbKgj3OoUFKmgA@mail.gmail.com>

On 01/09/15 17:42 +0200, Dmitry Vyukov wrote:
>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.

This looks good. Torvald suggested that it would be useful to add a
similar comment to the release operation in _M_dispose, so that both
sides of the release-acquire are similarly documented. Could you add
that and provide a suitable ChangeLog entry?

Thanks!


>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

  reply	other threads:[~2015-09-02 13:17 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
2015-09-02 13:17         ` Jonathan Wakely [this message]
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=20150902131752.GJ2631@redhat.com \
    --to=jwakely@redhat.com \
    --cc=dvyukov@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=glider@google.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).