在C++下編寫(xiě)synchronized method比較難 (1)
在Java中有叫做synchronized這樣一個(gè)方便的關(guān)鍵字。使用這個(gè)關(guān)鍵字的話,就可以像下面那樣能夠簡(jiǎn)單的進(jìn)行"同步"method. 然而,被同步的method并不表示它就能在多線程中同時(shí)被執(zhí)行.
public class Foo { 
public synchronized boolean getFoo() {
}
那么、在C++ (with pthread)中如何能實(shí)現(xiàn)同樣的功能呢? 首先,有一個(gè)最簡(jiǎn)單的方法就是下面這個(gè).
// 方法 a
void Foo::need_to_sync(void) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mutex);
// 臨界區(qū)處理
pthread_mutex_unlock(&mutex);
return;
}
這個(gè)方法, 暫且不說(shuō)C語(yǔ)言, 就是在C++中下面的若干問(wèn)題
- 在臨界區(qū)中間被return出來(lái)
- 在臨界區(qū)中間發(fā)生異常exception
發(fā)生的場(chǎng)合, mutex沒(méi)有被解鎖unlock。我們可以像下面代碼那樣對(duì)這點(diǎn)進(jìn)行改進(jìn).
// 方法 b
class ScopedLock : private boost::noncopyable {
public: explicit ScopedLock(pthread_mutex_t& m) : m_(m) {
pthread_mutex_lock(&m_);
}
~ScopedLock(pthread_mutex_t& m) {
pthread_mutex_unlock(&m_);
}
private:
pthread_mutex_t& m_;
};
void Foo::need_to_sync(void) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
{
// 雖然不加這個(gè)括號(hào)程序也沒(méi)有問(wèn)題。
ScopedLock lock(mutex);
// 在此處添加處理
}
return;
}
OK。return和異常的問(wèn)題就可以解決了. 但是, 上面并沒(méi)有完全解決這個(gè)問(wèn)題,仍然有下面這個(gè)問(wèn)題.
- 使用這個(gè)pthread_mutex_t并不是C++的.特別是存在下面的問(wèn)題:
- 不能和其他的Mutex類型做同樣的處理
- 與其他的Mutex類型使用同一個(gè)ScopedLock類,則不能lock
- Java的synchronized方法雖然可以"遞歸lock", 但是上面的代碼并不是這樣. 在臨界區(qū)中遞歸調(diào)用自己的話就會(huì)發(fā)生死鎖.
特別是,第2點(diǎn)的遞歸lock的問(wèn)題是很重要的. 這里好好地使用glibc擴(kuò)展的話就可以象下面那樣解決.
/ 方法 c
void Foo::need_to_sync(void) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP;
從NPpthread_mutex_init來(lái)初始化遞歸mutex,而pthread_mutex_init函數(shù)在一個(gè)線程中只能被調(diào)用一次. 如果想要用synchronized method的方法來(lái)實(shí)現(xiàn)這個(gè)的話,就變成了"是先有雞還是先有蛋"的話題了. 所以,用叫做pthread_once的函數(shù)來(lái)實(shí)現(xiàn)它,這也是在SUSv3中被記載的定則。
// 方法 d
namespace /* anonymous */ {
pthread_once_t once = PTHREAD_ONCE_INIT;
pthread_mutex_t mutex;
pthread_mutexattr_t attr;
void mutex_init() {
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&mutex, &attr);
}
}
void Foo::need_to_sync(void) {
pthread_once(&once, mutex_init);
{
ScopedLock lock(mutex);
// 処理
}
return;
}
上面的代碼就OK了。
這就能夠解決遞歸lock的問(wèn)題了.但是..., 這個(gè)方法
- 這越來(lái)越不像C++的代碼了.。對(duì)每一個(gè)想要同步(synchronize)的方法都像這么樣寫(xiě)代碼的話,效率變得非常低下.
- 隨機(jī)成本大。速度慢。
就會(huì)產(chǎn)生上面那樣的新問(wèn)題.
■[C++] 在C++下編寫(xiě)synchronized method比較難(2)
"不, 方法的同步應(yīng)該是經(jīng)常必需的, 并不是沒(méi)有方便的辦法",這樣的說(shuō)法也有吧. 是的, 有. 一般的辦法是下面那樣,
- 做成一個(gè)Mutex,作為(non-POD型的, 即普通的)C++類
- 做成一個(gè)Mutex類的實(shí)例,作為類變量, 或者是全局變量, 來(lái)同步化方法
來(lái)看看它的具體實(shí)現(xiàn)吧. 首先做成的Mutex類是下面那樣。
class Mutex {
public:
Mutex() {
pthread_mutex_init(&m_, 0);
}
void Lock(void) {
pthread_mutex_lock(&m_);
}
void Unlock(void) {
pthread_mutex_unlock(&m_);
}
private:
pthread_mutex_t m_;
};
現(xiàn)在的Mutex類,被作為抽象基類(接口類)的場(chǎng)合也比較多. 在這里就不說(shuō)了. ScopedLock類也需要有若干的修改. 想下面那樣寫(xiě)就好.
template<typename T> class ScopedLock {
public:
ScopedLock(T& m) : _m(m) {
_m.Lock();
}
~ScopedLock() {
_m.Unlock();
}
private:
T& _m;
};
用這個(gè)Mutex類來(lái)同步方法, 就可以像下面那樣寫(xiě). 首先是看看一個(gè)明顯的有錯(cuò)誤的例子.
// 方法e
void Foo::need_to_sync(void) {
static Mutex mutex;
{
ScopedLock<Mutex> lock(mutex);
// 処理
}
return;
}
這是... 代碼雖然簡(jiǎn)單易懂,但是很遺憾,它不能很好工作. NG!. Foo::need_to_sync函數(shù)第一次被執(zhí)行的時(shí)候如果恰好是多個(gè)線程同時(shí)執(zhí)行的話, mutex 的構(gòu)造函數(shù)就有被多次調(diào)用的可能性.關(guān)于理由，可以參考微軟中比較有名氣的blog文章The Old New Thing、在這里面有詳盡的描述，所以就我們就不在詳細(xì)敘述了。在這篇blog里使用了VC++的代碼作為例子，但是g++也是差不多的。所以“動(dòng)態(tài)的初始化局部的靜態(tài)變量”是， 在線程所完全意識(shí)不到的情況下進(jìn)行的。
接下來(lái)，要介紹一個(gè)在目前做的比較好的方法。 為了簡(jiǎn)單我們使用了全局變量，但是即使作為類變量（類中的static成員變量）也是一樣的。這個(gè)方法就是使用“非局部的靜態(tài)變量”來(lái)做成Mutex。
// 方法f
namespace /* anonymous */ {
Mutex mutex;
}
void Foo::need_to_sync(void) {
ScopedLock<Mutex> lock(mutex);
// 處理
return;
}
這個(gè)是最流行的方法，而且基本上可以沒(méi)有問(wèn)題就能工作得很好。
在一個(gè)全局的類對(duì)象x存在，且在x的構(gòu)造函數(shù)中直接或者繞彎間接的調(diào)用Foo::need_to_sync函數(shù)的場(chǎng)合，會(huì)引起一些問(wèn)題。也就是靜態(tài)的對(duì)象的初始化順序的問(wèn)題，這個(gè)問(wèn)題一般也被叫做"static initialization order fiasco" 。在執(zhí)行到mutex的構(gòu)造函數(shù)之前， mutex.Lock()有可能會(huì)被執(zhí)行。
這里的FAQ的10.12～10.16、在里面對(duì)自己的代碼的初始化順序已經(jīng)證明了沒(méi)有問(wèn)題，而且將來(lái)也不會(huì)出現(xiàn)問(wèn)題，所以上面的方法是OK的。
如果， 初始化順序的問(wèn)題不能保證他沒(méi)有問(wèn)題的話， 只好使用pthread_once的“方法d”，或者移植性低的“方法c”。我的個(gè)人感覺(jué)是方法c還是比較不錯(cuò)的選擇。
在最后我們嘗試考慮一下如何把方法c變成C++的代碼。
// 方法c (重新討論)
void Foo::need_to_sync(void) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP;
目標(biāo)是、
- 隱藏pthread_mutex_t類型、讓自己寫(xiě)的類的類型可見(jiàn)。
- 在方法e,f中像使用ScopedLock模板那樣進(jìn)行修改。
當(dāng)然，不讓它發(fā)生初始化順序的問(wèn)題。
■[C++] 用C++編寫(xiě)synchronized method比較難 (3)
這是方法c的改良。 首先， 為了避免發(fā)生初始化順序的問(wèn)題， 必須是不允許調(diào)用構(gòu)造函數(shù)就能完成對(duì)象的初始化。因此，必須像下面那樣初始化mutex對(duì)象
// 方法c' (假設(shè))
void Foo::need_to_sync(void) {
static StaticMutex mutex = { PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP, ........ };
一般的不允許像這樣初始化C++類。為了實(shí)現(xiàn)上面那樣的初始化，StaticMutex類必須是POD型的。所謂POD型就是，
- 不允許有構(gòu)造函數(shù)
- 不允許有析構(gòu)函數(shù)
- 不允許編譯器生成拷貝構(gòu)造函數(shù)， 賦值構(gòu)造函數(shù)。
- 不允許有private, protected 的成員
- 不允許有虛函數(shù)
滿足以上規(guī)格的類型。
大概有嚴(yán)格的制約,但是利用"定義非虛成員函數(shù)是沒(méi)有問(wèn)題的"這個(gè)特性, 我們嘗試改良方法c的方案.
...像下面那樣如何?
// 方法c'
#define POD_MUTEX_MAGIC 0xdeadbeef
#define STATIC_MUTEX_INITIALIZER { PTHREAD_INITIALIZER, POD_MUTEX_MAGIC }
#define STATIC_RECURSIVE_MUTEX_INITIALIZER { PTHREAD_RECURSIVE_INITIALIZER_NP, POD_MUTEX_MAGIC }
class PODMutex {
public:
void Lock() {
assert(magic_ == POD_MUTEX_MAGIC);
pthread_mutex_lock(&mutex_);
}
void Unlock() {
assert(magic_ == POD_MUTEX_MAGIC);
pthread_mutex_unlock(&mutex_);
}
typedef ScopedLock<PODMutex> ScopedLock;
public:
// 雖然編程了POD型, 但是不定義成public就是無(wú)效的
pthread_mutex_t mutex_;
const unsigned int magic_;
};
// ScopedLock類模板是留用了在方法e,f中做成的代碼.
void Foo::need_to_sync(void) {
static PODMutex mutex = STATIC_RECURSIVE_MUTEX_INITIALIZER;
{
PODMutex::ScopedLock lock(mutex);
// 處理.
}
return;
}
上面的代碼滿足了"隱藏了pthread_mutex_t型,留用了ScopedLock<>"這兩個(gè)目的. 這不就是有點(diǎn)兒像C++的代碼了嗎? 還有,PODMutex類型是即使在上記例子中那樣的局部靜態(tài)變量以外,也能放心的使用全局變量,類變量了.
而且, 成員變量 magic_ 是, 一個(gè)const成員變量, 所以當(dāng)使用編譯器自動(dòng)生成的構(gòu)造函數(shù)來(lái)創(chuàng)建一個(gè)對(duì)象時(shí)就會(huì)發(fā)生錯(cuò)誤. 因此,在構(gòu)建release版程序時(shí)把它剔除就好了.
使用g++ -S來(lái)編譯上面的代碼, 生成匯編代碼. 我們就能看見(jiàn)下面那樣的局部的靜態(tài)變量.
$ g++ -S sample.cpp
$ c++filt < sample.s | lv
(略)
.size Foo::need_to_sync()::mutex, 28
Foo::need_to_sync()::mutex:
.long 0
.long 0
.long 0
.long 1
.long 0
.long 0
.long -559038737
0,0,0,1,0,0 這樣的東西是 PTHREAD_RECURSIVE_INITIALIZER_NP , -559038737 則是 POD_MUTEX_MAGIC 。即使沒(méi)有進(jìn)行動(dòng)態(tài)的初始化(不調(diào)用構(gòu)造函數(shù))、僅僅是在目標(biāo)文件上生成的目標(biāo)代碼那樣的進(jìn)行靜態(tài)初始化, mutex對(duì)象也能被正常的初始化, 所以這段代碼是OK的.
隨便, 在使用boost庫(kù)的場(chǎng)合, 方法f之外的選擇余地幾乎沒(méi)有(至少是現(xiàn)在). 一看見(jiàn)ML等, (當(dāng)然!!)就知道可能會(huì)出現(xiàn) order順序的問(wèn)題. 但是, 就目前來(lái)講, 既要保證既要保證可移植性*7和速度,又要能做成與方法c相當(dāng)?shù)腜ODMutex的方法好像還沒(méi)有出現(xiàn)吧.
完結(jié)