1. 可以不用單件, 程序開始時全局new出來, 以后不用鎖,直接用就好.
2. 既然全是靜態數據, 還需要用Singleton呢?
3. 用Interlock會更高效  回復  更多評論
  

之前看過一個，建議將構造弄成 私有的，生成實例由 GetInstatnce來做
別人new是new不了的  回復  更多評論
  

依然不是線程安全的。  回復  更多評論
  

去看看ZThread中的單件吧

以前的話我會推薦loki的
但是現在歸納絕那個太復雜了  回復  更多評論
  

@OwnWaterloo
您好，首先感謝您對本隨筆的關注。懇請您說詳細一點，我不太明白哪些地方還不是線程安全的。  回復  更多評論
  

@OnTheWay
class S
{
S() { ... }
~S(); { ... }
S(S const&);
S& operator=(S const&S);

public:
static S& instance()
{
static S s;
return s;
}

};

你認為C++(C++03）是否保證S::instance是線程安全的？
如果是， 請說明理由。
如果C++不保證， 是否應該將S::instance作成線程安全的？
  回復  更多評論
  

@OnTheWay
再來一種：

class S
{
// ctor, copy, dtor, assignment
static S s_;
public:
S& instance() { return s_; }
};

S S::s_;

同樣是上面的問題。
  回復  更多評論
  

@OwnWaterloo
我覺得不是線程安全的，原因如下：
在你給出的代碼中類S中的函數（雖然現在我還沒有想不出這種函數）可能不是線程安全的。

我的MSN是wwj_5_209@163.com，能否加我一下，我們討論一下。  回復  更多評論
  

@OwnWaterloo
與博文中的不是一回事。  回復  更多評論
  

@OnTheWay
注意兩種需要運行時初始化的靜態對象， s和s_。
前者的初始化時機C++有保證， 但不保證多線程安全。
后者的初始化時機C++只保證同一翻譯單元內中有順序。

再看static CAssistForSingleton m_refSycObj;
這就屬于第2種。

下面的情況有發生的可能性：
1. 另一翻譯單元的靜態對象先于m_refSycObj被初始化
2. 在它初始化時訪問了CSingleton *GetInstatnce()

此時就訪問了一個"未初始化"的臨界區。
這已經是bug。

再有， 如果有下列情況：
1. 一些先于m_refSycObj初始化的代碼開啟了線程
2. 多個線程在m_refSycObj初始化前訪問CSingleton *GetInstatnce()

一個未初始化的m_refSycObj根本不能用于同步。

所以， 上面的第1個問題： 這樣做不是多線程安全的。


而靜態對象在構造時啟動線程的情況并不多， 所以并不一定需要將s_作成多線程安全。
例如boost就是這樣， 要求在進入main之前， 是不許有兩條以上的執行路徑去訪問。
這就是第2個問題。


如果需要完全的多線程安全：
1. 使用once_initial函數(pthread或者win6有提供）
2. 使用"可以靜態初始化"的鎖， 比如pthread_mutex_t就可以
或者自己使用一個spinlock也行。

我沒有msn…… 用gmail的同名郵箱。
  回復  更多評論
  

@匿名
知道什么叫"舉一反三"嗎？
  回復  更多評論
  

個人一點隨想：我覺得應該從實際應用的邏輯上來進行線程安全的分析，并根據現實情況的分析避免不必要的加解鎖操作。某些代碼只是一種理想化的東西?，F實中有太多比SetData復雜的邏輯。而且也不一定需要加鎖。當然從你這個代碼看，GetInstatnce當然是正確的哈。  回復  更多評論
  

傻逼實現也好意思貼出來？丟人現眼  回復  更多評論
  

@OnTheWay
c++里的線程安全單例應該是典型的雙重檢測.
文中如此實現的話, 每次調用GetInstatnce都要涉及到加鎖操作, 估計沒人愿意調用.   回復  更多評論
  

沒有用volatile，顯然不是線程安全的  回復  更多評論