WebRTC源代码探索之旅——多线程篇（2）

2 crticalsection

 

criticalsection.h/criticalsection.cc文件中包含了3个类talk_base::CriticalSection、talk_base::CritScope和talk_base::TryCritScope。这3个类对于有多线程编程经验的Windows开发人员来说都是非常容易理解的。基本上就是对Win32 CriticalSection的简单封装。

 

2.1 talk_base::CriticalSection

 

talk_base::CriticalSection主要实现了跨平台实现临界区的功能。在Linux平台上使用了pthread的mutex模拟Win32的Critical Section。以下对比一下API：

 

InitializeCriticalSection

 

pthread的mutex初始化略比Win32的CriticalSection复杂一些。pthread_mutexattr_init函数用来初始化一个mutex属性变量。pthread_mutexattr_settype函数用来设置mutex的各种属性。在talk_base::CriticalSection中为mutex设置了PTHREAD_MUTEX_RECURSIVE。通过网上查询该属性被描述为：

 

“如果一个线程对这种类型的互斥锁重复上锁，不会引起死锁，一个线程对这类互斥锁的多次重复上锁必须由这个线程来重复相同数量的解锁，这样才能解开这个互斥锁，别的线程才能得到这个互斥锁。如果试图解锁一个由别的线程锁定的互斥锁将会返回一个错误代码。如果一个线程试图解锁已经被解锁的互斥锁也将会返回一个错误代码。这种类型的互斥锁只能是进程私有的（作用域属性为PTHREAD_PROCESS_PRIVATE）。”

 

通过设置不同的属性pthread mutex可以实现很多不同的特性。如果读者有兴趣可以上网查询一下不同的属性的意义。不过需要注意到的是在talk_base::Event类中没有mutex属性，直接使用默认值创建了mutex。接着使用talk_base::CriticalSection使用pthread_mutex_init函数创建了mutex。最后请不要忘记调用pthread_mutexattr_destroy将mutex属性变量销毁掉。

 

DeleteCriticalSection

 

pthread_mutex_destroy函数用以销毁mutex。

 

EnterCriticalSection

 

pthread_mutex_lock函数用以对mutex加锁。

 

TryEnterCriticalSection

pthread_mutex_trylock函数用以尝试对mutex加锁，如果加锁成功就返回true，失败就返回false。

 

LeaveCriticalSection

 

pthread_mutex_unlock函数用以解锁mutex.

 

在talk_base::CriticalSection中有个调试宏CS_TRACK_OWNER。如果使用了这个宏，talk_base::CriticalSection可以使用CurrentThreadIsOwner函数用来判断是否是在当前线程加锁。在的段落重点提到过talk_base::CriticalSection使用PTHREAD_MUTEX_RECURSIVE属性来创建mutex，该属性导致在另一个线程线程(非加锁线程)解锁mutex会返回一个错误。

 

2.2 talk_base::CritScope

利用构造函数加锁talk_base::CriticalSection；并利用析构函数在退出代码块的时候解锁talk_base::CriticalSection。该手法对于所有C++开发人员并不陌生。

  

2.3 talk_base::TryCritScope

 

类似于talk_base::CritScope，利用构造函数尝试加锁talk_base::CriticalSection；并利用析构函数在退出代码块的时候解锁talk_base::CriticalSection。

 

对于大多数熟练的Win32开发人员来说前两个文件的内容是很好理解的，不过是2道开胃菜而已。接着我们要真正开始进入分析多路信号分离器的范围了。这也是多线程篇的重点部分。我会尽可能详细的分析整个多路信号分离器的工作原理。不过也会抛弃一些实现细节，比如所有的代码分析都是基于“永久”等待信号事件的流程，不会去分析如何计算下一次等待时间。这样可以让我们更加专注于多路信号分离器的原理，而不被一些细节困扰。