From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 695DA3858417; Mon, 29 May 2023 01:47:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 695DA3858417
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685324849;
	bh=z3tEDJDE8P2yuvGqxffKI5I+f8c2M0pHU09PYjcFaSU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=iVo2cRtPkTyftVyLAOZtd3ALSemNOOKe3JOpqG/Yk+KhKhaMXxC8NrMEDqDeeiuYg
	 mCknqiw5q6vGE1y3dkfeIq/P3Soo89x5UjyqRuA2Bm322UFOPrbXo6jWgPtbCfK0iR
	 gPBAKDsH/rMg0IsAN3B9lOAfe9ETep/F8srGcnMI=
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 01:47:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 12.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110016-4-cBDrGjwzjU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110016-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110016-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So I think this is a bug in your code:

Inside substrate::threadPool_t::finish,
we have:

                        finished =3D true;
                        haveWork.notify_all();

If I change it to:
                        {
                          std::lock_guard<std::mutex> lock{workMutex};
                          finished =3D true;
                          haveWork.notify_all();
                        }

Then I don't get a deadlock at all.
As I mentioned, I did think there was a race condition.
Here is what I think happened:
Thread26:                            thread 1
checks finished, still false         sets finished to be true
calls wait                           calls notify_all
...                                  notify_all happens
finally gets into futex_wait syscall ....

And then thread26 never got the notification.

With my change the check for finished has to wait till thread1 lets go of t=
he
mutex (and the other way around).=