mutex的加锁与解锁问题

[zhaokai3000]

有一个进程，创建了2个线程，线程A和线程B，线程A与线程B都需要访问某一资源。
所以在进程中初始化了一个pthread_mutex_t变量resMutex;
pthread_mutex_init(&resMutex, NULL);

线程A的工作：
for (i=0;i<100;i++)
{
pthread_mutex_lock(&resMutex);
use resource
pthread_mutex_unlock(&resMutex);
}

线程B平时读消息队列，收到消息后执行一次如下操作：
pthread_mutex_lock(&resMutex);
use resource
pthread_mutex_unlock(&resMutex);

发现执行情况：
线程A lock mutex
线程A 访问资源
线程B lock mutex 阻塞
线程A unlock mutex
线程A lock mutex
线程A 访问资源
线程A unlock mutex
...
线程A的工作执行完，最后一次unlock mutex
线程B lock mutex 成功返回
线程B 访问资源
线程B unlock mutex

就是线程A工作时，线程B一直抢占不到mutex。
查了下手册，默认的mutex类型应该是PTHREAD_MUTEX_TIMED_NP，按手册来说，这种锁当一个线程加锁以后，其余请求锁的线程将形成一个等待队列，并在解锁后按优先级获得锁。
线程A加锁后，只有线程B请求锁，那么为什么线程A解锁后，线程B并没有马上得到锁，而是线程A下一循环周期的加锁请求又得到锁了呢？

然后我尝试了一下，在线程A解锁后加了一点延时，线程B就能够在线程A本周期解锁后得到锁了。

求解

[昵称很不好取]

抢占的吧，A线程的for循环是否是一个原子操作，如果是把锁拿到for循环外面
可以试试sleep(0)

[zhaokai3000]

不是原子操作。
你是说默认mutex是抢占式的？

[justkk]

貌似mutex就是这个特性，以前见过这方面的讨论
信号灯机制就是队列方式访问的

[zhaokai3000]

呃，如果是队列方式的话，那按说线程B比线程A下一周期先请求的锁，不是应该排的比较靠前？
虽然开始我已经通过在线程A的pthread_mutex_unlock后加usleep延时一点时间解决了问题，但是还是挺奇怪。
我的这个进程是在arm11的linux下运行的（2.6.36）。

我试了一下写了个简化版的测试程序：

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

pthread_mutex_t tstmutex;

void ThreadFnc(int *threadno);

int main(void)
{
   int num1;
   int num2;  
   pthread_t    thread1;
   pthread_t    thread2;
   pthread_mutexattr_t  attr;
   int type;

   pthread_mutexattr_init(&attr);
   if (pthread_mutex_init(&tstmutex, &attr) < 0)
   {
      printf("pthread_mutex_init failed.\n");
      return -1;
   }

   num1 = 1;
   if (pthread_create(&thread1, NULL, (void *)ThreadFnc, (void *)&num1) < 0)
   {
      printf("pthread_create thread1 failed.\n");
   }
   usleep(5000);
   num2 = 2;
   if (pthread_create(&thread2, NULL, (void *)ThreadFnc, (void *)&num2) < 0)
   {
      printf("pthread_create thread2 failed.\n");
   }

   pthread_join(thread1, NULL);
   pthread_join(thread2, NULL);
     
   pthread_mutex_destroy(&tstmutex);
   return 0;
}

void ThreadFnc(int *threadno)
{
  int i=0;
  
  if (*threadno == 1)
  {
     for(i=0; i< 5; i++)
     { 
        printf("thread %d try to lock mutex. \n", *threadno);
        if (pthread_mutex_lock(&tstmutex) < 0)
        {
           printf("pthread_mutex_lock failed.\n", *threadno);
        }
        printf("pthread_mutex_locked by thread %d.\n");
 	sleep(1);
        printf("thread %d try to lock mutex.\n", *threadno);
        if (pthread_mutex_unlock(&tstmutex) < 0)
        {
           printf("pthread_mutex_unlock failed.\n");
        }
        printf("pthread_mutex_unlocked by thread %d.\n", *threadno);
     }
  }
  else
  {
     printf("thread %d try to lock mutex. \n", *threadno);
     if (pthread_mutex_lock(&tstmutex) < 0)
     {
        printf("pthread_mutex_lock failed.\n", *threadno);
     }
     printf("pthread_mutex_locked by thread %d.\n");
     sleep(1);
     printf("thread %d try to lock mutex.\n", *threadno);
     if (pthread_mutex_unlock(&tstmutex) < 0)
     {
        printf("pthread_mutex_unlock failed.\n");
     }
     printf("pthread_mutex_unlocked by thread %d.\n", *threadno);
  }
}

在虚拟机上的Fedora Linux 2.6.25下运行结果固定如下：
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 2 try to lock mutex.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 2.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
thread 2 try to lock mutex.
pthread_mutex_locked by thread 1.
pthread_mutex_unlocked by thread 2.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
可看出，线程1第一周期解锁后，线程2即加锁成功。

但是在arm下linux 2.6.36运行结果：
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 2 try to lock mutex.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_locked by thread 1.
thread 1 try to lock mutex.
pthread_mutex_unlocked by thread 1.
pthread_mutex_locked by thread 2.
thread 2 try to lock mutex.
pthread_mutex_unlocked by thread 2.

对内核是在是不懂，求高手指教。

[zhaokai3000]

thread 2 的pthread_mutex_unlock前的打印信息写错了。凑合看吧。。。

[zhaokai3000]

up一下。继续求解

[toadzw]

因为A的线程周期没有用完啊，一直在运行，所有一段时间内一定时A，然后一段时间内B在跑啊，如果你的处理部分大一点，会出现A,B来回跑的情况了

[zhaokai3000]

[Quote=引用 7 楼 toadzw 的回复:]
因为A的线程周期没有用完啊，一直在运行，所有一段时间内一定时A，然后一段时间内B在跑啊，如果你的处理部分大一点，会出现A,B来回跑的情况了
[/Quote]

不明白你的意思。或者你没明白我的问题。。

[LeoricKing]

我想可能是这样的：
线程之间切换需要切换内核级别（5000ns）
执行i<10,然后近跳转 是两个内存访问 （i的地址和 jmp地址） 大概需要30ns。

我也比较菜 可能有谬误。敬请指正！

[LeoricKing]

也就是说这个30NS是不够内核给线程B发消息。让B获得这个资源的。

[zhaokai3000]

[Quote=引用 10 楼 leoricking 的回复:]
我想可能是这样的：
线程之间切换需要切换内核级别（5000ns）
执行i<10,然后近跳转 是两个内存访问 （i的地址和 jmp地址） 大概需要30ns。

我也比较菜 可能有谬误。敬请指正！
[/Quote]

抱歉有段时间没来看。

看来我得多看看内核工作原理方面的书。
谢谢回复。

[nilite]

1、首先线程锁默认不是队列式的，每次解锁以后，所有的锁都要重新竞争。所以很有可能线程A在每次解锁以后都能抢到锁，但是可怜的线程B每次都抢不到锁。这个跟线程的调度策略有关。
2、如果不想更改默认的调度策略，那么线程A或者线程B在释放锁以后，调用sched_yield()让出cpu。
3、也可以更改默认的调度策略为SCHED_FIFO，调用函数pthread_attr_setschedpolicy(&tattr, SCHED_FIFO);具体用法请参考《linux多线程编程手册》

[zaghost]

CPU太快了吧
加个sleep(0)放弃CPU看看

据说PTHREAD_MUTEX_TIMED_NP的结尾的NP表示不可移植，不知道有影响没

[LeoricKing]

服务器死了 又得重写一遍。。
自己实验了下 当i==10000的时候才会出现明显的线程切换现象。

猜想：
当A线程放弃资源之前，会告诉内核，然后内核查看申请队列。如果是空，就继续让A持有资源。
如果有线程申请该资源，A线程会放弃该资源。但这是个漫长的过程。
因此在这个过程中，A继续能获得B资源。

当过了N年之后，线程B知道了 ，A资源已经跟A线程分离了 才能趁虚而入。
十三楼的说法，不能够解释A线程持续持有资源的情形。线程调度基本上有两种 1是先来先服务 2是优先级高的先服务。明显这里 用的是现来先服务。 但是B线程一直没有得到内核发出的A资源已经可以被使用的信号。所以A资源占了点便宜。能够继续占有资源。 cpu处理跟IO设备的时间差，才是操作系统存在的根本原因。时间差是王道阿。

[南京浪人甲]

在A锁外（加锁前或解锁后）面加一个sleep(xx)，否则B是抢不到锁的