我用pthread编写了一个多线程程序,使用生产者-消费者模型。
当我使用 Intel VTune profiler 来分析我的程序时,我发现生产者和消费者在 pthread_mutex_unlock 上花费了大量时间。我不明白为什么会这样。我认为线程可能会等待很长时间才能获取互斥体,但是释放互斥体应该很快,对吗?
下面的快照来自 Intel VTune。它显示了消费者尝试从缓冲区获取项目的代码,以及每个代码行消耗的时间。
My question is that why pthread_mutex_unlock has such overhead? Is the problem with pthread mutex itself or with the way I use it?
The pthread_mutex_unlock()
函数应释放互斥体引用的互斥体对象。但是,释放互斥锁的方式取决于互斥锁的类型属性。如果在以下情况下,互斥体引用的互斥体对象上有线程被阻塞pthread_mutex_unlock()
被调用,导致互斥体变得可用,调度策略应确定哪个线程应获取互斥体。
如果互斥体类型是PTHREAD_MUTEX_NORMAL
,不应提供死锁检测。尝试重新锁定互斥锁会导致死锁。如果线程尝试解锁尚未锁定的互斥锁或已解锁的互斥锁,则会导致未定义的行为。
如果互斥体类型是PTHREAD_MUTEX_ERRORCHECK
,则应提供错误检查。如果线程尝试重新锁定已锁定的互斥体,则应返回错误。如果线程尝试解锁尚未锁定的互斥体或已解锁的互斥体,则应返回错误。
如果互斥体类型是PTHREAD_MUTEX_RECURSIVE
,那么互斥锁应保留锁计数的概念。当线程第一次成功获取互斥锁时,锁计数应设置为 1。每次线程重新锁定该互斥体时,锁定计数应加一。每次线程解锁互斥体时,锁定计数应减一。当锁计数达到零时,互斥锁将可供其他线程获取。如果线程尝试解锁尚未锁定的互斥体或已解锁的互斥体,则应返回错误。
如果互斥体类型是PTHREAD_MUTEX_DEFAULT
,尝试递归锁定互斥体会导致未定义的行为。如果调用线程未锁定互斥锁,则尝试解锁该互斥锁会导致未定义的行为。如果互斥锁未锁定,则尝试解锁该互斥锁会导致未定义的行为。
我通常更喜欢使用PTHREAD_MUTEX_RECURSIVE
互斥锁,因为在这种情况下,当计数达到零并且调用线程不再对此互斥锁具有任何锁定时,互斥锁将变得可用。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)