一直覺得自己的寫的乙個對臨近區呼叫的乙個封裝類很無敵，簡簡單單就搞定了乙個物件內部的執行緒同步，如果
有全域性變數的話，搞定多個物件的執行緒同步也不是很難，現在看了下atl的原始碼，原來和人家畢竟低等的
封裝一模一樣，慚愧啊。
先看看人家對section的封裝吧，
class ccomcriticalsection
~ccomcriticalsection()
hresult lock() throw()
hresult unlock() throw()
hresult init() throw()
// structured exception may be raised in low memory situations
__except(status_no_memory == getexceptioncode())
return hres;
}hresult term() throw()
critical_section m_sec;
};這個就是簡單的對section封裝了一下子，把裡面的操作換了個更陽春的名字罷了，沒有什麼大不了的。
class ccomautocriticalsection : public ccomcriticalsection
~ccomautocriticalsection() throw()
private :
hresult init(); // not implemented. ccomautocriticalsection::init should never be called
hresult term(); // not implemented. ccomautocriticalsection::term should never be called
};這個就是在上面的基礎上加了在建構函式初始化和在析構函式中反初始化的操作（自己編的詞）
class ccomsafedeletecriticalsection : public ccomcriticalsection
~ccomsafedeletecriticalsection() throw()
m_binitialized = false;
ccomcriticalsection::term();
}hresult init() throw()
return hr;
}hresult term() throw()
m_binitialized = false;
return ccomcriticalsection::term();
}hresult lock()
private:
bool m_binitialized;
};加了個安全保障而已嘛，這些看起來還蠻平凡的。我除了沒有它寫的精細外，大體還是一樣的。
如果單有這個基本可以算是個簡單的封裝了，在同步開始呼叫lock,在結束的時候呼叫unlock 就可以了，但如果有異常的時候
就不行了，如果有異常發生，那麼unlock很可能沒有呼叫，這個對於執行緒同步是致命的。不過不要緊，這個我都搞得定，
使用乙個類包一層，在構造的時候加鎖，在析構的時候解鎖就ok了，atl也是這麼想的。
template< class tlock >
class ccomcritseclock
;template< class tlock >
inline ccomcritseclock< tlock >::ccomcritseclock( tlock& cs, bool binitiallock ) :
m_cs( cs ),
m_blocked( false )}}
template< class tlock >
inline ccomcritseclock< tlock >::~ccomcritseclock() throw()
}template< class tlock >
inline hresult ccomcritseclock< tlock >::lock() throw()
m_blocked = true;
return( s_ok );
}template< class tlock >
inline void ccomcritseclock< tlock >::unlock() throw()
很明顯的，這個就是和我想的一模一樣的，就是加了個什麼模板，可以選擇上面的section封裝，這些基本是為了
執行緒模型用，可以選擇安全的，也可以為了效率不安全一點，同時有的時候只有乙個執行緒在玩，沒有必要加什麼
鎖嘛，就有個什麼fake 的section類，來玩個假的花樣，就是調了跟沒調一樣。
ccomsinglethreadmodel就是這樣乙個東西，它就是定義了乙個這種叫做ccomfakecriticalsection的東西來玩同步
基本就是沒有同步，而ccommutithreadmodel就是老老實實的同步，它就用了criticalsection.
也就是說，繼承了這兩種模型類的一種，也就決定了section的封裝類，反正他們最後都被定義成了autocriticalsection
的東西。
最後奇怪的是，這個什麼seclock它最後沒有用，在ccomobjectrootex中，選擇的乙個_autodelcritsec的成員section
它是threadmodel的autodeletecriticalsection,就是那個不能呼叫term的傢伙，在它裡面還有乙個真正的sectionlock ,這個lock
和ccomobjectrootex使用一樣的執行緒模型模板，同時它在構造的時候加鎖，在析構的時候解鎖，用的就是這個成員section
在使用的時候，物件由於繼承了ccomobjectrootex那麼它就直接有了這個幾個成員變數，那麼在它用同步的函式中，直接定義乙個
objectlock，然後將自己的指標作為引數傳入就可以了，這樣相當於把成員鎖傳入了，這樣ccomobjectlockt就可以實現我剛才說
的功能了，過程是複雜了點，但功能有點像.net中的使用,在物件自身中放個同步的鎖，在成員函式要同步的時候，使用
issynchronze(this)就可以了，和這裡的使用有點類似。
下面就是這個簡單的ccomobjectlockt，和剛才的那個簡直就是一樣的。
template
class ccomobjectlockt
~ccomobjectlockt()
ccomobjectrootex* m_p;
};
ATL 執行緒池的使用
class cmyworker 必須實現以上介面 具體參考如下 demo long g lcurrid 1 class cmyworker virtual bool initialize void pvparam virtual void terminate void pvparam virtual...
關於執行緒安全的學習
背景 最近在學習一套庫函式，因為涉及到資料的讀寫操作，所以庫函式提供了lock與unlock函式用於對寫操作進行保護。需要保護的原因是函式庫沒有自己的執行緒，它們執行在庫函式呼叫者的執行緒中 所以如果沒有保護機制，如果出現多個執行緒同時去做寫資料操作就會導致共享資料出錯 這類函式也稱之為非執行緒安全...
執行緒安全與鎖優化
樂觀鎖 cas aba 版本號 atomicstampedreference 時間戳atomicmarkablereference boolean 可重入 絕對執行緒安全，不依賴共享資料 使用引數，區域性變數 自旋鎖 認為鎖很快釋放，占用cpu迴圈獲取鎖，超過一定次數 時間 再掛起執行緒，自旋次數上...