问题：

有一个进程，创建了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线程持续持有资源

求解

 

 

 

 

理解解释：

 

 服务器死了 又得重写一遍。。

自己实验了下 当i==10000的时候才会出现明显的线程切换现象。

 

猜想： 

  当A线程放弃资源之前，会告诉内核，然后内核查看申请队列。如果是空，就继续让A持有资源。

   如果有线程申请该资源，A线程会放弃该资源。但这是个漫长的过程。

   因此在这个过程中，A继续能获得B资源。

 

当过了N年之后，线程B知道了  ，A资源已经跟A线程分离了 才能趁虚而入。

 

线程调度基本上有两种 1是先来先服务 2是优先级高的先服务。明显这里 用的是先来先服务。 但是B线程一直没有得到内核发出的A资源已经可以被使用的信号。所以A资源占了点便宜。能够继续占有资源。  cpu处理跟IO设备的时间差，才是操作系统存在的根本原因。时间差是王道啊。

 

 

 

我的理解:

A设备解锁,内核发布告诉申请这个资源的线程们,这个资源可以抢了.原则:先来先服务.

然后A/B开始抢资源,资源A设备刚用完,还在A设备手上.所以A设备立即抢,时间花费极小;

但是B从收到抢的信号到开始抢,需要花费一定的时间,肯定抢不过A设备的.

所以A理所当然的把资源抢到了,然后加锁,内核就宣布本回合结束.资源被A设备抢到,A设备可以用,其他设备等待.

所以B就不抢了,继续等待如此循环下去了….所以A一直占用资源,B一直抢不到.