[Bug libstdc++/110016] Possible miscodegen when inlining std::condition_variable::wait predicate causes deadlock

["pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> So I think this is a bug in your code:
> 
> Inside substrate::threadPool_t::finish,
> we have:
> 
>                         finished = true;
>                         haveWork.notify_all();
> 
> If I change it to:
>                         {
>                           std::lock_guard<std::mutex> lock{workMutex};
>                           finished = 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
> the mutex (and the other way around).

I should note that adding -fsanitize=thread increases the time between checking
of finished and getting into the wait which increases the chances of the race
condition of finished changing to true and notify_all happens before the wait
has happened.

I can prevent this race condition from showing up by adding:
        for(volatile int i = 0 ; i < 10000;i ++) ;
Right before the call to finish method in main. because it forces a "sleep"
before setting of finished variable which is enough time to pass on the other
thread to get into the wait state.

Though the race condition might show up when adding work queue entries still
and then calling finish method.

It is not even an ABA issue that is mentioned in PR 98033 as the predicate
never changes from false to true back to false. In this case it is false and
then true, but we never saw the change because that thread never got a
notification as it was not in wait when the notifications were sent out.