由 tpp.c:63: __pthread_tpp_change_priority failed 引发的思考

本文主要是介绍由 tpp.c:63: __pthread_tpp_change_priority failed 引发的思考，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

早上在测试一个程序的时候，同事发现了我们的程序出现了 tpp.c:63: __pthread_tpp_change_priority failed的错误报告。当时同事查了这方面的资料，发现是线程互斥锁（pthread_mutex_t）的缘故，并假设了出错的原因。关于这个我们还讨论了一阵。自己有些地方想不明白，于是向同事要了一些链接看了看。

因为这一段程序是我写的，所以想把自己出错的原因找到。Google了一下，找到了一些解释（见注释1）。

下边的这张图就是自己使用mutex的程序结构：

按照自己的理解，两个线程会交互运行。当时同事说不是。在这一点我们有争执。但是查过了一些资料，发现这样确实存在不是交互运行的情况。

于是自己在自己的PC和ARM平台上做了测试。

测试如下：

代码：                                                  

        sleep(1);                                                              
        printf("%s: %d\n", __func__, __LINE__);
        pthread_mutex_unlock(&sMutex);
#ifdef  T_SLEEP

发现这里PC平台上，和ARM平台上的多线程运行结果有很大的不同。在PC上从第一个运行的线程来看，是先创建的线程先运行；而ARM平台上是后创建的线程先运行。这里不知道是否是因为GCC版本不同造成的。同时关于线程间的切换可以看到，在ARM平台上如果在解锁后不调用usleep()，两个线程只有一个线程在运行。

对于不同平台的程序测试要注意！

在单核CPU下，Linux的多线程切换，有时候并不是和我们想象的那样。

tpp.c下出错的源代码片段（完整见注）：

61:   assert (new_prio == -1
62:          || (new_prio >= __sched_fifo_min_prio
63:              && new_prio <= __sched_fifo_max_prio));
64:   assert (previous_prio == -1
65:          || (previous_prio >= __sched_fifo_min_prio
66:              && previous_prio <= __sched_fifo_max_prio));

在有一篇帖子中看到作者的调试记录，发现是在63行处，是new_prio的值太大了，导致assert出错。这里是NPTL线程库中的函数出现了问题。

看到解决方案是设置mutex的属性，由默认的快速互斥锁修改为递归互斥锁就可以解决这个问题。

> The initialisation of the mutex is being done as follows:
>
> ---
> pthread_mutexattr_t mutexattr;
>
Just guessing: no pthread_mutexattr_init()!> // Set the mutex as a recursive mutex
> pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_RECURSIVE_NP);

（……）

注1：

几个链接：

这篇关于由 tpp.c:63: __pthread_tpp_change_priority failed 引发的思考的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---