欲加速，故生并發(fā)之策，存臨界不可達(dá)，故而生
鎖，阻塞患于
鎖，固又生避阻之策。。。
此刻主要想記錄下關(guān)于并發(fā)中
鎖相關(guān)的內(nèi)容，當(dāng)然，我也只想記錄一些真正有效用的東西。
可以說
鎖是衍生自并發(fā)，故談并發(fā)必然至
鎖。
此篇不欲從減少臨界區(qū)以提高并發(fā)度的角度來考慮，不會(huì)深度探索諸如如何基于CAS來構(gòu)建高質(zhì)量無
鎖數(shù)據(jù)結(jié)構(gòu)等。
而是從反方向，從如何很好的運(yùn)用
鎖策略的角度來考慮。
這里要強(qiáng)調(diào)的一點(diǎn)是，無論如何，臨界區(qū)
在一個(gè)系統(tǒng)中基本上是必然存
在的。CAS的確可以
在很多地方通過自身機(jī)制來消去
鎖以達(dá)到化解臨界區(qū)之目的。但是這個(gè)實(shí)現(xiàn)復(fù)雜度卻又著實(shí)提升了，況且，也不是所有地方都能夠或者值得去CAS。相比而言，
鎖比較容易理解。
好了，切入主題：并發(fā)之------
鎖策略!
好，首先是定界加
鎖策略。
定界加鎖(Scoped Locking)：能確保當(dāng)控制進(jìn)入到某一范圍時(shí)，自動(dòng)獲得
鎖，而當(dāng)控制離開范圍時(shí)，自動(dòng)釋放
鎖，不管從該范圍返回的路徑是什么。
給段普通的
C++代碼sample:
bool increment(const string &path) {
Item *item = lookup_or_create(path);
lock.acquire();
if(entry==0){
lock.release();
return false;
} else {
entry->increment_hit_count();
lock.release();
return true;
}
}
這段代碼完全可以正常工作，但是lock.acquire()和lock.release()之間存
在著多路返回，如果以上情況復(fù)雜點(diǎn)，寫代碼的人不一定記得
在每個(gè)返回點(diǎn)都釋放
鎖。OK, 就算情況不復(fù)雜，拿上面的例子來看，如果entry->increment_hit_count()拋出了個(gè)異常，那如何？？？很顯然，
鎖得不到釋放了，這顯然會(huì)導(dǎo)致其它想要得到
鎖的線程永遠(yuǎn)阻塞。
那怎么樣避免呢？定界加
鎖模式是正用于此。
你可以定義個(gè)哨兵類(guard)類，當(dāng)控制進(jìn)入一個(gè)區(qū)域時(shí)，哨兵類的
構(gòu)造函數(shù)自動(dòng)獲得一個(gè)
鎖，當(dāng)控制離開這個(gè)區(qū)域時(shí)，哨兵類的析構(gòu)函數(shù)自動(dòng)釋放該
鎖，因?yàn)楦鶕?jù)
C++的語義，即便
在程序中拋出一個(gè)異常，析構(gòu)函數(shù)還是會(huì)執(zhí)行。將哨兵類實(shí)例化，以
在定義臨界區(qū)的方法和塊區(qū)域中獲得或釋放
鎖。類似于autoPoint的手法，需要注意的是：一，
在哨兵類中要使用指向
鎖的指針而不是使用棧上
鎖對(duì)象，以防止對(duì)
鎖的復(fù)制或賦值；二，給哨兵類增加一個(gè)owner標(biāo)志，用來表示哨兵是否成功獲得了
鎖，該標(biāo)志也可以指示當(dāng)錯(cuò)誤地使用靜態(tài)/全局
鎖時(shí)，由“初始化錯(cuò)誤”而導(dǎo)致的失敗。通過
在析構(gòu)函數(shù)中檢查這個(gè)標(biāo)志，可以避免當(dāng)哨兵釋放它并不擁有的
鎖而產(chǎn)生的運(yùn)行時(shí)錯(cuò)誤。
哨兵類代碼示范：
class Thread_Mutex_Gurad {
public:
Thread_Mutex_Guard(Thread_Mutex &lock):lock_(&lock), owner_ (false){
lock_->acquire();
owner_ = true;
}
~Thread_Mutex_Guard(){
if(owner_) lock_->release();
}
private:
Thread_Mutex *lock_;
bool owner_;
Thread_Mutex_Guard(const Thread_Mutex_Guard &);
void operator=(const Thread_Mutex_Guard &);
};
以上模式是基于
C++的特性來玩的。
C++棧對(duì)象離開作用域時(shí)，必然調(diào)用其析構(gòu)，這是死規(guī)則，所以這樣OK。
再拿java作下對(duì)比，如果使用synchronized關(guān)鍵字，OK,你不用理會(huì)上面的麻煩，JVM幫你搞定。但如果你用的是
ReentrantLock或者ReadWriteLock之類，那么，下面的寫法基本上就是死規(guī)矩了。
lock.lock();
try{
} finally{
lock.unlock();
}
以上代碼不能顯示獲取和釋放
鎖，你可以很簡單的給它加上。
現(xiàn)
在懶得寫東西了，下文后續(xù)補(bǔ)上。。。。。。
java下也有個(gè)finalize方法來做實(shí)例的資源銷毀，但是JVM作GC的時(shí)機(jī)不確定，并非對(duì)象離開作用域就立馬調(diào)用。所以你不要拿java的
鎖對(duì)豍