stl 執行緒安全性
摘錄：
在所有的主流stl實現方案中，幾乎所有的容器都是執行緒安全的:
1).乙個執行緒讀寫乙個例項時，另乙個執行緒可以讀寫另乙個例項。
2).多個執行緒可以在同時讀同乙個container。
3).多個執行緒讀寫同乙個container時，你應該負責安排互斥性操作。
乙個特例是std::string。在一些stl的實現廠商（包括ms vc6），使用的是帶引用計數的string! 這就意味著可能有兩個std::string的例項共享著同一塊底層資料。這使得前面說的第乙個規則被打破!
看一下這樣的**：
string s1= 「abcd」;
string s2 = s1;
在引用計數的實現版本中，這幾句話意味著：先分配一塊記憶體給」abcd」，乙個引用計數的數；s1和s2都將引用這塊記憶體，引用計數將為2。引用計數的本意是在把strings傳出functions時優化copy行為。
但是這種演算法並不是執行緒安全的!
如果你將s2傳給另乙個執行緒，那麼就很可能有兩個執行緒企圖修改這同一塊記憶體!那將會有不可預料的行為發生。
理論上，你可以在兩個執行緒之間增加執行緒同步，但是這個同步的代價將會大於你從引用計數中獲得的好處!
這就是為什麼主流的stl廠商不再使用引用計數的原因。比如，dinkumware stl shipped with vc7。
visual c++的stl並不是thread-safe，在它的allocator中，沒有針對thread的同步問題做過任何特殊的設計，如果你用multi-thread操作同乙個list container的話，最好自己完成同步方面問題；但如果你使用的是stlport提供的stl或者sgi stl的話，就應該是thread-safe，它的allocator做過一些特殊的設計
執行緒安全性
定義 當多個執行緒訪問某個類時，不管執行環境採用何種呼叫方式或者這些執行緒如何交替執行，並且在主調 中不需要任何額外的同步或者協同，這個類都能表現出正確的行為，那麼就稱這個類是執行緒安全的。主要表現三個方面 atomic cas unsafe.compareandswapint atomiclong...
執行緒安全性
執行緒安全性 當多個執行緒訪問某個類時，這個類始終都能表現出正確的行為，那麼稱這個類是執行緒安全的。執行緒不安全產生的問題 競態條件 由於不恰當的執行時序而出現不正確的結果。大多數競態條件的本質是基於一種可能失效的觀察結果來做出判斷或者執行某個計算。常見先檢查後執行，延遲初始化 單例模式 讀取 修改...
2執行緒安全性
當多個執行緒訪問可變的同乙個狀態變數沒有正確的同步，那麼就會出現錯誤，有三種方式可以修復這種錯誤 將狀態變數修改為不可變的變數 在訪問狀態變數時使用同步 編寫併發應用程式的時候，一種準確地程式設計方式是 首先使 正確執行，然後在提高 的速度。即便如此，最好也只是當測試結果和應用需求告訴你必須提高效能...