From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A2B34385042F; Sun, 1 Nov 2020 13:58:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A2B34385042F From: "malteskarupke at fastmail dot fm" To: glibc-bugs@sourceware.org Subject: [Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing Date: Sun, 01 Nov 2020 13:58:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.27 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: malteskarupke at fastmail dot fm X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 13:58:23 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25847 Malte Skarupke changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |malteskarupke at fastmail = dot fm --- Comment #11 from Malte Skarupke --- I blogged about trying to understand this bug using TLA+ here: https://probablydance.com/2020/10/31/using-tla-in-the-real-world-to-underst= and-a-glibc-bug/ TLA+ is a tool for doing program verification. I'll make the code available= in any license you want. (I presume LGPL is good?) I think it would be good to have a TLA+ implementation of the condition variables in glibc. My solution for this bug based on the investigation would be to broaden the scope of g_refs, so that it gets incremented in line 411 in pthread_cond_wait.c, and gets decremented in line 54. That makes it align exactly with the increment and decrement of wrefs, which might make wrefs unnecessary. (though I didn't verify that) If it does make wrefs unnecessar= y, this fix could both simplify the code, speed it up a little, and also get r= id of the "potential stealing" case. I haven't yet done the work to actually implement and try that change. Let = me know if there is interest in me trying that. (or also let me know if it's unlikely to work because I missed something) --=20 You are receiving this mail because: You are on the CC list for the bug.=