Could you kindly explain this modification about pthread_cond_destroy?

[honan li <sayibobo@gmail.com>]

We came across a Linux app issue that while invoke
pthread_cond_destroy, it is pending there forever. After investigation
we find that is because a waiter is being blocked (by
pthread_cond_wait) while doing pthread_cond_destroy.

This issue didn't occur on our previous platform using
glibc2.20(Yocto1.7), while it always occurs after we upgraded to
Yocto2.2(includs glibc after version 2.24). We checked glibc history
and find issue seems related to commit ed19993b5 by Torvald Riegel on
31 Dec 2016.

We do noticed the comment of __pthread_cond_destroy, it mentioned "A
correct program must make sure that no waiters are blocked on the
condvar when it is destroyed.", "It must also ensure that no signal or
broadcast are still pending to unblock waiters." and "destruction that
is concurrent with still-active waiters is probably neither common nor
performance critical.".
But back to our issue, on the Qualcomm platform we are working on,
there are many places invoking pthread_cond_destroy, but after each
pthread_cond_destroy, thread or even the process would exit, and at
least for now it seems working all right on glibc2.20. Could you
kindly explain what is the potential risk of the case?

//below is the simple app to verify the issue. App always got stuck on
pthread_cond_destroy on glibc2.25, while on glibc2.20 it ends well.
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
void *thread1(void *);
void *thread2(void *);
int main(void)
{
     pthread_t t_a;
     pthread_t t_b;
     pthread_create(&t_a,NULL,thread1,(void *)NULL);
     pthread_create(&t_b,NULL,thread2,(void *)NULL);
     sleep(1);

     pthread_cond_destroy(&cond);
     pthread_mutex_destroy(&mutex);
     exit(0);
}
void *thread1(void *args)
{
    pthread_cond_wait(&cond,&mutex);
}
void *thread2(void *args)
{
}