问题描述
我在使用互斥锁时遇到问题(在Linux上为pthread_mutex)，如果一个线程在解锁后再次锁定互斥锁，则另一个线程获取锁的成功率不是很高.我已经附上了创建一个互斥锁的测试代码，以及两个线程，它们在一个无限循环中锁定了该互斥锁，休眠一会儿然后再次将其解锁.
我希望看到的输出是两个线程的活动"消息，每个线程一个(例如121212121212.)但是，我得到的是一个线程获得了大多数锁(例如111111222222222111111111111或仅1111111111111 ...). /p>
如果在解锁后添加usleep(1)，则一切正常.显然，当该线程进入SLEEP时，另一个线程获得了它的锁-但这不是我期望的那样，因为另一个线程已经调用了pthread_mutex_lock.我怀疑这是实现该方法的方式，因为actice线程具有优先级，但是在此特定测试用例中会引起某些问题.有什么方法可以防止它(除了故意增加足够大的延迟或某种信号)，还是我的理解错误在哪里?
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <unistd.h>
pthread_mutex_t mutex;
void* threadFunction(void *id) {
int count=0;
while(true) {
pthread_mutex_lock(&mutex);
usleep(50*1000);
pthread_mutex_unlock(&mutex);
// usleep(1);
++count;
if (count % 10 == 0) {
printf("Thread %d alive\n", *(int*)id);
count = 0;
}
}
return 0;
}
int main() {
// create one mutex
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutex_init(&mutex, &attr);
// create two threads
pthread_t thread1;
pthread_t thread2;
pthread_attr_t attributes;
pthread_attr_init(&attributes);
int id1 = 1, id2 = 2;
pthread_create(&thread1, &attributes, &threadFunction, &id1);
pthread_create(&thread2, &attributes, &threadFunction, &id2);
pthread_attr_destroy(&attributes);
sleep(1000);
return 0;
}
您误解了互斥体的工作方式(至少在您的特定实现中如此).互斥锁的释放不会自动交换到另一个等待它的线程.
通常，线程一直运行，直到它们不得不等待资源或耗尽其时间(时间片)为止.
在没有资源争用且所有线程具有相同优先级的情况下，最公平的调度算法是在交换之前给每个相等的时间片.这是因为交换操作本身会花费一些时间，所以您不想做得太频繁(相对于线程正在执行的实际工作.
如果要在线程之间交替，则需要比互斥锁更具确定性的东西，例如一组条件变量:
I am having a problem with mutexes (pthread_mutex on Linux) where if a thread locks a mutex right again after unlocking it, another thread is not very successful getting a lock. I've attached test code where one mutex is created, along with two threads that in an endless loop lock the mutex, sleep for a while and unlock it again.
The output I expect to see is "alive" messages from both threads, one from each (e.g. 121212121212. However what I get is that one threads gets the majority of locks (e.g. 111111222222222111111111 or just 1111111111111...).
If I add a usleep(1) after the unlocking, everything works as expected. Apparently when the thread goes to SLEEP the other thread gets its lock - however this is not the way I was expecting it, as the other thread has already called pthread_mutex_lock. I suspect this is the way this is implemented, in that the actice thread has priority, however it causes certain problem in this particular testcase. Is there any way to prevent it (short of adding a deliberately large enough delay or some kind of signaling) or where is my error in understanding?
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <unistd.h>
pthread_mutex_t mutex;
void* threadFunction(void *id) {
int count=0;
while(true) {
pthread_mutex_lock(&mutex);
usleep(50*1000);
pthread_mutex_unlock(&mutex);
// usleep(1);
++count;
if (count % 10 == 0) {
printf("Thread %d alive\n", *(int*)id);
count = 0;
}
}
return 0;
}
int main() {
// create one mutex
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutex_init(&mutex, &attr);
// create two threads
pthread_t thread1;
pthread_t thread2;
pthread_attr_t attributes;
pthread_attr_init(&attributes);
int id1 = 1, id2 = 2;
pthread_create(&thread1, &attributes, &threadFunction, &id1);
pthread_create(&thread2, &attributes, &threadFunction, &id2);
pthread_attr_destroy(&attributes);
sleep(1000);
return 0;
}
You misunderstand the way that mutexes work (at least under your particular implementation). The release of a mutex doesn't automatically swap to another thread that's waiting for it.
Generally, threads keep running until either they have to wait for a resource or they use up their quantum (time slice).
Where there is no resource contention and all threads have the same priority, the fairest scheduling algorithm is to give each an equal time slice before swapping. That's because the swap operation itself takes some time so you don't want to be doing it too often (relative to the real work being done by the threads.
If you want to alternate between threads, you need something more deterministic than mutexes, such as a set of condition variables:
这篇关于永久互斥锁导致死锁?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！