本文分析在Linux應(yīng)用程序中錯(cuò)誤使用pthread_mutex鎖時(shí)會(huì)概率性觸發(fā)SIG_ABRT信號(hào)而導(dǎo)致程序崩潰（庫(kù)打印輸出 ：Assertion `mutex->__data.__owner == 0' failed）的原因。

程序環(huán)境如下：（1）Glibc-2.15 （2）Linux-4.1.12 （3）樹莓派1b

首先給出出錯(cuò)的示例程序：

#include <stdio.h>  
#include <unistd.h>  
#include "pthread.h"  
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;    
void * process(void * arg)  
{  
	fprintf(stderr, "Starting process %s\n", (char *) arg);  
	while (1) {
		/* 加鎖等待某些資源 */
		pthread_mutex_lock(&lock);
		fprintf(stderr, "Process %s lock mutex\n", (char *) arg);  
		/* 加鎖成功表示資源就緒 */
		usleep(1000);
		/* do something */
	}
	return NULL;  
}  
int main(void)  
{  
	pthread_t th_a, th_b;  
	int ret = 0;  
	ret = pthread_create(&th_a, NULL, process, "a");  
	if (ret != 0) fprintf(stderr, "create a failed %d\n", ret);  
	ret = pthread_create(&th_b, NULL, process, "b");  
	if (ret != 0) fprintf(stderr, "create b failed %d\n", ret);  
	while (1) {
		/* 等待并檢測(cè)某些資源就緒 */
		/* something */
		/* 解鎖告知線程資源就緒 */
		pthread_mutex_unlock(&lock); 
		fprintf(stderr, "Main Process unlock mutex\n");  
	}
	return 0;  
}  

本示例程序中，main函數(shù)首先創(chuàng)建兩個(gè)線程,，然后主線程等待某些資源就緒（偽代碼,，程序中未體現(xiàn)），待就緒后解鎖mutex lock以告知子線程可以執(zhí)行相應(yīng)的處理（在解鎖后打印輸出解鎖成功）,，不斷循環(huán),；創(chuàng)建出的兩個(gè)線程均調(diào)用process函數(shù)，該函數(shù)會(huì)嘗試加鎖mutex lock,，加鎖成功則表示資源就緒可以處理（打印輸出加鎖成功）,，否則在鎖上等待，亦往復(fù)循環(huán),。本程序中對(duì)mutex鎖的用法特殊,，并不對(duì)臨界資源進(jìn)行保護(hù)，而是作為線程間”生產(chǎn)---消費(fèi)“同步功能的一個(gè)簡(jiǎn)化示例,，加鎖以等待資源就緒,，解鎖以通知資源就緒，加鎖和解鎖的操作分別在不同的線程中執(zhí)行,。

運(yùn)行該程序后不到10s時(shí)間程序就會(huì)出錯(cuò)退出,，并且觸發(fā)SIG_ABRT信號(hào)，終端打印輸出如下：

......

程序在Glibc庫(kù)中的pthread_mutex_lock.c的第62行__pthread_mutex_unlock()函數(shù)中出錯(cuò),，程序ABRT退出,。

下面先來(lái)分析對(duì)應(yīng)的源碼，首先是加鎖流程：

加鎖函數(shù)源碼：

int
__pthread_mutex_lock (mutex)
     pthread_mutex_t *mutex;
{
  assert (sizeof (mutex->__size) >= sizeof (mutex->__data));
  unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
  if (__builtin_expect (type & ~PTHREAD_MUTEX_KIND_MASK_NP, 0))
    return __pthread_mutex_lock_full (mutex);
  pid_t id = THREAD_GETMEM (THREAD_SELF, tid);
  if (__builtin_expect (type, PTHREAD_MUTEX_TIMED_NP)
      == PTHREAD_MUTEX_TIMED_NP)								//1---判斷鎖類型
    {
    simple:
      /* Normal mutex.  */
      LLL_MUTEX_LOCK (mutex);									//2---加鎖（原子操作）
      assert (mutex->__data.__owner == 0);						//3---Owner判斷
    }
  ...
  /* Record the ownership.  */
  mutex->__data.__owner = id;									//4---Owner賦值
#ifndef NO_INCR
  ++mutex->__data.__nusers;
#endif
  return 0;
}

解鎖函數(shù)源碼：

int
internal_function attribute_hidden
__pthread_mutex_unlock_usercnt (mutex, decr)
     pthread_mutex_t *mutex;
     int decr;
{
  int type = PTHREAD_MUTEX_TYPE (mutex);
  if (__builtin_expect (type & ~PTHREAD_MUTEX_KIND_MASK_NP, 0))
    return __pthread_mutex_unlock_full (mutex, decr);
  if (__builtin_expect (type, PTHREAD_MUTEX_TIMED_NP)				//1---判斷鎖類型
      == PTHREAD_MUTEX_TIMED_NP)
    {
      /* Always reset the owner field.  */
    normal:
      mutex->__data.__owner = 0;						//2---Owner解除
      if (decr)
	/* One less user.  */
	--mutex->__data.__nusers;
      /* Unlock.  */
      lll_unlock (mutex->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex));		//3---原子解鎖
      return 0;
    }
    ...
}

LLT_MUTEX_LOCK()函數(shù)返回繼續(xù)執(zhí)行,。

以上就是調(diào)用pthread mutex函數(shù)加解鎖函數(shù)的主要流程,，其中需要關(guān)注的一點(diǎn)就是這兩個(gè)函數(shù)的執(zhí)行并不是原子的，是可能存在上下文切換動(dòng)作的,。在通常的用法中,，我們加鎖操作一般都是為了保護(hù)臨界資源不被重入改寫，一半都是嚴(yán)格按照“加鎖-->寫入/讀取臨界資源-->解鎖”的流程執(zhí)行（由加鎖的線程負(fù)責(zé)解鎖）,，而從前文中分析的__pthread_mutex_lock()和__pthread_mutex_unlock_usercnt()函數(shù)中也可以看到,，只有在原子加鎖期間才會(huì)改變這__owner值（該值也可認(rèn)為是臨界資源的一部分而被保護(hù)起來(lái)了），因此是不可能出現(xiàn)加鎖已經(jīng)加鎖的線程的,，所以也不會(huì)調(diào)用assert()函數(shù)而退出程序的,。

但是本程序中對(duì)鎖的用法顯然并不這么“一般”，而是作為一種線程間的同步功能使用,。其中主進(jìn)程中不停的解鎖,，即是線程A和B沒(méi)有加鎖也同樣如此，而線程A和B會(huì)競(jìng)爭(zhēng)的每隔一定時(shí)間去加鎖,，那么就有可能出現(xiàn)如下圖中所示的一種情況：1,、

該圖中主進(jìn)程待資源就緒后正在解鎖一個(gè)未被加鎖的mutex_lock時(shí)發(fā)成了線程切換，線程A打斷解鎖流程完成了一整個(gè)加鎖的流程,，隨后線程又且換回了主進(jìn)程繼續(xù)執(zhí)行真正的解鎖操作,，這樣線程A所加的鎖就被莫名其妙的解掉了（關(guān)鍵的一點(diǎn)），此時(shí)若線程B在等待該鎖,，則會(huì)進(jìn)入到加鎖流程,，從而在加鎖成功后崩潰在這個(gè)__owner判斷上。其實(shí)該程序出錯(cuò)的主要原因即是解了并未加鎖的mutex_lock,，如若主進(jìn)程解得鎖是已經(jīng)上了鎖的,，則線程A是沒(méi)有機(jī)會(huì)加鎖的，主進(jìn)程會(huì)原子的完成整個(gè)mutex_unlock動(dòng)作,。

另外,，其實(shí)可以適當(dāng)?shù)恼{(diào)整程序再來(lái)看一下另外一種可能的情形（兩個(gè)執(zhí)行流），同樣是“線程間同步”用法：2,、

這種情況就是在資源就緒較慢且資源處理較快的情況容易出現(xiàn)崩潰,，同樣是概率性出現(xiàn)的。最后來(lái)看第三種可能的情況：3,、

這種情況崩潰出現(xiàn)在線程A加鎖的過(guò)程中被主進(jìn)程解鎖,，然后線程A或其他線程又一次加鎖的時(shí)候。其實(shí)不論上述哪一種同步的情況,，其出錯(cuò)的原因有兩點(diǎn)：（1）解了未被上鎖的鎖,；（2）A線程加的鎖由其他線程去解，進(jìn)一步分析就是沒(méi)有嚴(yán)格按照“加鎖-->解鎖”的流程使用mutex鎖。

最后對(duì)于以上這種“線程間同步”的使用方法可以使用條件變量或者是信號(hào)量實(shí)現(xiàn)而不要使用mutex鎖,，mutex鎖一般被用在保護(hù)線程間臨界資源的情況下,。

總結(jié)：

1、不要去解鎖一個(gè)未被加鎖的mutex鎖,；

2,、不要一個(gè)線程中加鎖而在另一個(gè)線程中解鎖；

3,、使用mutex鎖用于保護(hù)臨界資源,，嚴(yán)格按照“加鎖-->寫入/讀取臨界資源-->解鎖”的流程執(zhí)行，對(duì)于線程間同步的需求使用條件變量或信號(hào)量實(shí)現(xiàn),。