如何解释 libpthread 上的 glibc 修改？

Question

我们在将 Yocto 从 1.7 升级到 2.2 时发现了一个问题。下面的应用程序在较新的 glibc 上表现不同，在 glibc2.25 上它总是卡在 pthread_cond_destroy，而在 glibc2.20 上它运行良好。

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)
{
}

经过调查，我在这里找到了一个 glibc 提交： https://sourceware.org/git/?p=glibc.git;a=commit;f=sysdeps/arm/nptl/bits/pthreadtypes.h;h=ed19993b5b0d05d62cc883571519a67dae481a14，好像是这个原因。

我们注意到__pthread_cond_destroy的评论，其中提到：

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.

从我的角度来看，它带来了一个缺陷。但 glibc 团队似乎有充分的理由。谁能解释一下这个修改是否有必要？

Answer 1

来自standard：

Attempting to destroy a condition variable upon which other threads
are currently blocked results in undefined behavior.

From my perspective it brings in a defect.

您的程序依赖于未定义的行为。现在你为此付出了代价。

如何解释 libpthread 上的 glibc 修改？

How to explain this glibc modification on libpthread?

glibc

pthreads

yocto