[EXTERNAL] Re: Deadlock question re: pthread_cond_wait

[Matthew Renzelmann]

Thank you all for your fast response and quick diagnosis of the bug – I indeed overlooked this case and it’s definitely my bug.  I believe you’re right that I’m simply destroying the event before it’s being signaled, which is certainly incorrect.  Sorry for the confusion, and again, thank you for your (fast) help!
Matt

From: Godmar Back <godmar@gmail.com>
Sent: Thursday, January 16, 2025 12:13 PM
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Matthew Renzelmann via Libc-help <libc-help@sourceware.org>; Matthew Renzelmann <mrenz@microsoft.com>
Subject: [EXTERNAL] Re: Deadlock question re: pthread_cond_wait

You don't often get email from godmar@gmail.com<mailto:godmar@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
On Thu, Jan 16, 2025 at 3:07 PM Florian Weimer <fw@deneb.enyo.de<mailto:fw@deneb.enyo.de>> wrote:

Not a concurrency expert, though.  I don't know if we're supposed to
have spurious wakeups like that.

I don't think spurious wakeups are involved. The example has a loop (albeit a weird one using unnecessary atomic loads) that ensures that the waiter won't bail out until State is true. The trouble is that the subsequent calls to cond_destroy in the waiter and cond_signal in the setter are concurrent (nothing enforces any particular ordering), so with different interleaving/execution the destroy can occur before the signal as I showed in my demo.

 - Godmar