public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/110016] Possible miscodegen when inlining std::condition_variable::wait predicate causes deadlock
Date: Mon, 29 May 2023 15:37:53 +0000	[thread overview]
Message-ID: <bug-110016-4-HIBw0EDkMw@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110016-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rachel Mant from comment #14) 
> To properly understand this problem space, why do you think locking the
> mutex before setting `finished` is sufficient to fix this? It feels to us
> like it shouldn't, and should only mask the bug, making it less likely to
> trigger?

So currently wait (and the check of finished) is under the mutex, workMutex. If
you want to modify finish, it needs to be under the same mutex.


Note https://en.cppreference.com/w/cpp/thread/condition_variable mentiones the
exact fix too.

And even has the following: "Even if the shared variable is atomic, it must be
modified while owning the mutex to correctly publish the modification to the
waiting thread."

(this part was added back in 2015:
https://en.cppreference.com/mwiki/index.php?title=cpp/thread/condition_variable&diff=81211&oldid=80448
)

So I think I can now close this as invalid.

  parent reply	other threads:[~2023-05-29 15:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 21:11 [Bug c++/110016] New: [12/13/14] " amy at amyspark dot me
2023-05-28 21:44 ` [Bug libstdc++/110016] " pinskia at gcc dot gnu.org
2023-05-29  0:47 ` [Bug libstdc++/110016] " amy at amyspark dot me
2023-05-29  1:03 ` pinskia at gcc dot gnu.org
2023-05-29  1:05 ` pinskia at gcc dot gnu.org
2023-05-29  1:05 ` pinskia at gcc dot gnu.org
2023-05-29  1:20 ` pinskia at gcc dot gnu.org
2023-05-29  1:27 ` pinskia at gcc dot gnu.org
2023-05-29  1:34 ` pinskia at gcc dot gnu.org
2023-05-29  1:47 ` pinskia at gcc dot gnu.org
2023-05-29  6:43 ` pinskia at gcc dot gnu.org
2023-05-29 13:30 ` rachel at rachelmant dot com
2023-05-29 14:28 ` pinskia at gcc dot gnu.org
2023-05-29 15:15 ` pinskia at gcc dot gnu.org
2023-05-29 15:18 ` rachel at rachelmant dot com
2023-05-29 15:37 ` pinskia at gcc dot gnu.org [this message]
2023-05-29 20:38 ` redi at gcc dot gnu.org

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=bug-110016-4-HIBw0EDkMw@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.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).