青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

cexer

cexer
posts - 12, comments - 334, trackbacks - 0, articles - 0
  C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

轉帖請注明出處 http://m.shnenglu.com/cexer/archive/2008/07/08/55670.html

  單件(Singelton)模式可以說是眾多設計模式當中,理解起來最容易,概念最為簡單的一個。并且在實際的設計當中也是使用得又最為頻繁的,甚至有很多其它的模式都要借助單件才能更好地實現。然而就是這樣被強烈需求的“一句話模式”(一句話就能闡述明白),雖然有無數的牛人浸淫其中,至今也沒有誰鼓搗出一個完美的實現。我小菜鳥一只自然更不敢逢人便談單件。不過這個貼的主題是跟單件模式是密不可分的。

  什么又叫做“線程相關的單件模式”呢?也許你已經顧名思義猜出了八九分。不過還是允許我簡單地用實例說明一下。

  假設你要設計了一個簡單的 GUI 框架,這個框架當中需要這樣一個全局變量(單件模式),它保存了所有窗口句柄與窗口指針的映射(我見過的數個的開源 GUI 框架都有類似的東西。)。在 WIN32 平臺上就是這樣一個簡單的東西:

    //窗口的包裝類
class Window
{
HWND m_hwnd;
public:
bool create();
bool destroy();

//其它細節
};

//窗口句柄與其對象指針的映射
typedef map<HWND,Window*> WindowMap;
typedef WindowMap::iterator WindowIter;
WindowMap theWindowMap;




  每創建一個窗口,就需要往這個 theWindowMap 當中添加映射。每銷毀一個窗口,則需要從其中刪除掉相關映射。實現代碼類似:

    //創建窗口
bool Window::create()
{
m_hwnd=::CreateWindow(/*參數略*/);
if(!::IsWindow(m_hwnd))
return false;

theWindowMap[m_hwnd]=this; //添加映射
return true;
}

//銷毀窗口
bool Window::destroy()
{
::DestroyWindow(m_hwnd);

theWindowMap.erase(m_hwnd); //刪除映射
return true;
}


  你可以用任何可能的單件模式來實現這樣一個全局變量 theWindowMap,它會 工作得很好。但是當如果考慮要給程序添加多線程支持(“多線程”是如此麻煩,它總愛和“但是”一起出現,給本來進行得很順利的事情引起波折。),就會發現此時也許純粹的單件模式并不是最好的選擇。例如一個線程同時創建窗口,那么兩個線程同時調用:

    theWindowMap[m_hwnd]=this;


  這顯然不是一個原子操作,可以肯定如果你堅持這樣干你的程序會慢慢走向崩潰,幸運一點只是程序運行結果錯誤,如果你恰好那幾天印堂發暗面色發灰,說不定就因為這小小的錯誤,被無良的BOSS作為借口開除掉了,那可是個悲慘的結局。

  當然大多數的單件模式已經考慮到了多線程的問題。它們的解決方案就是給加上線程鎖 ,我在數個開源的 GUI 框架看到他們都采用了這種解決方案。不過這樣做,在線程同步過程當中,會產生與 GUI 框架邏輯不相關的同步消耗,雖然不是什么大不了的消耗,但是客戶可能因此就選擇了你的竟爭對手,如果線程竟爭激烈,在強烈渴求資源的環境(如小型移動設置)當中,這種消耗更是不可忽視的。

  實際上在應用當中,極少有線程需要插入刪除其它線程創建的窗口映射(如果確實有這種需要,那么可以肯定項目的設計上出了問題)。在這種情況下本線程創建窗口映射都將只是本線程存取,類似“Thread-Specific”的概念。也就是說,theWindowMap 當中其它線程創建的窗口的映射對于本線程來說都是不需關心的,我們卻要為那部分不必要東西整天提心吊膽并付出運行時消耗的代價,這也有點像“穿著棉襖洗澡”。但是怎么樣才能做到更輕松爽快些呢?

  就本例問題而言,我們需要這樣一種變量來保存窗口映射,它針對每個線程有不同的值(Thread-Specific Data),這些值互不影響,并且所有線程對它的訪問如同是在訪問一個進程內的全局變量(Singelton)。

  如果你是熟悉多線程編程的人,那么“Thread-Specific ”一定讓你想起了什么。是的,“Thread-Specific Storage ” (線程相關存存諸,簡稱 TSS ),正是我們需要的,這是大多數操作系統都提供了的一種線程公共資源安全機制,這種機制允許以一定方式創建一個變量,這個變量在所在進程當中的每個線程當中,可以擁有不同的值。在 WIN32 上,這個變量就稱為“索引”,其相關的值則稱為“槽”, “Thread-Local Storage”(線程局部存諸,簡稱 TLS )機制。它的提了供這樣幾個函數來定義,設置,讀取線程相關數據(關于 TLS 的更多信息,可以查閱 MSDN ):

    //申請一個“槽”的索引。
DWORD TlsAlloc( void );

//獲得調用線程當中指定“槽”的值。
VOID* TlsGetValue( DWORD dwTlsIndex );

//設置調用線程當中指定“槽”的值。
BOOL TlsSetValue( DWORD dwTlsIndex,VOID* lpTlsValue );

//釋放掉申請的“槽”的索引
BOOL TlsFree( DWORD dwTlsIndex );

  具體使用流程方法:先調用 TlsAlloc 申請一個“索引”,然后線程在適當時機創建一個對象并調用 TlsSetValue 將“索引”對應的“槽”設置為該對象的指針,在此之后即可用 TlsGetValue 訪問該“糟”。最后在不需要的時候調用 TlsFree ,如在本例當中,調用 TlsFree 的最佳時機是在進程結束時。

  先封裝一下 TlsAlloc 和 TlsFree  以方便對 ”索引“的管理。

    class TlsIndex
{
public:
TlsIndex()
:m_index(::TlsAlloc())
{}

~TlsIndex()
{
::TlsFree(m_index);
}

public:
operator DWORD() const
{
return m_index;
}

private:
DWORD m_index;
};

  
  如你所見,類 TlsIndex 將在構造的時候申請一個“索引”,在析構的時候釋放此“索引”。

  在本例當中 TlsIndex 的對象應該存在進程的生命周內,以保證在進程退出之前,這個“索引”都不會被釋放,這樣的 TlsIndex 對象聽起來正像一個全局靜態對象,不過 Meyers Singelton (用函數內的靜態對象實現)在這里會更適合,因為我們不需要對這個對象的生命周末進行精確控制,只需要它在需要的時候創建,然后在進程結束前銷毀即可。這種方式只需要很少的代碼即可實現,比如:

    DWORD windowMapTlsIndex()
{
static TlsIndex s_ti;  //提供自動管理生命周期的“索引”
return s_ti;
}


  利用這個“索引”,我們就能實現上述“Thread-Specific”的功能:

    WindowMap* windowMap()
{
WindowMap* wp=reinterpret_cast<WindowMap*>(::TlsGetValue(windowMapTlsIndex()));
if(!wp)
{
wp=new WindowMap();
::TlsSetValue(windowMapTlsIndex(),wp);
}
return wp;
}

#define theWindowMap *(windowMap())

  
  注意各線程訪問以上的代碼不會存在竟爭。這樣就實現了一個線程安全且無線程同步消耗版本的“全局對象” theWindowMap 。我們甚至不用改變Window::create,Window::destory,queryWindow 的代碼,

  這幾個簡單的函數看起來似乎不像一個“模式”,但是它確實是的。

  現在總結一下“線程相關的單件模式”的概念:保證一個類在一個線程當中只有一個實例,并提供一個訪問它的線程內的訪問點的模式。

  為了不重復地制造車輪,我將此類應用的模式封裝了一下:

    template<typename TDerived>
class TlsSingelton
{
typedef TDerived _Derived;
typedef TlsSingelton<TDerived> _Base;

public:
static _Derived* tlsInstance()
{
return tlsCreate();
}

protected:
static _Derived* tlsCreate()
{
_Derived* derived=tlsGet();
if(derived)
return derived;

derived=new _Derived();
if(derived && TRUE==::TlsSetValue(tlsIndex(),derived))
return derived;

if(derived)
delete derived;

return NULL;
}

static bool tlsDestroy()
{
_Derived* derived=tlsGet();
if(!derived)
return false;

delete derived;
return true;
}

static DWORD tlsIndex()
{
static TlsIndex s_tlsIndex;
return s_tlsIndex;
}

private:
static _Derived* tlsGet()
{
return reinterpret_cast<_Derived*>(::TlsGetValue(tlsIndex()));
}

static bool tlsSet(_Derived* derived)
{
return TRUE==::TlsSetValue(tlsIndex(),derived);
}

//noncopyable
private:
TlsSingelton(const _Base&);
TlsSingelton& operator=(const _Base&);
};


  將 tlsCreate,tlsDestroy 兩個函數設置為保護成員,是為了防止一些不三不四吊爾啷噹的程序隨意地刪除。

  示例:

    class WindowMapImpl:public TlsSingelton<WindowMap>
{
WindowMap m_map;
public:
WidnowMap& theWindowMapImpl()
{
return m_map;
}

public:
~WindowMapImpl();

protected:
WindowMapImpl(); //只能通過tlsCreate創建
friend class _Base;
};

#define theWindowMap (WindowMapImpl::tlsInstance()->theWindowMapImpl())



  仍不需要修改原有窗口代碼。

Feedback

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-09 16:57 by www.helpsoff.com.cn
哈哈,有意思!看到一半的時候,心想有必要引入tls嗎,只要設好編譯選項,map應該是線程安全的呀;不過看到后面,把tls引入然后封裝到原有實現上去,覺得很精彩,其實已經跳出了討論所謂singleton和線程安全的范疇了,雖然目的是這個。

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-09 18:32 by cexer
呵呵謝謝耐心看完。map可以通過編譯器設置線程安全?我還不知道呢。不過引入tls與“線程相關的單件”,是為了可以讓更多更復雜的此類應用更容易實現。還有map的線程安全是由實現提供的(非標準),應該不是所有編譯器都支持的吧?

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-10 01:44 by www.helpsoff.com.cn
我大致記得用cl編譯鏈接生成binary的時候帶"/MT"就是連接多線程庫,不過印象不深了,博主有興趣可以看看。

我同意博主的說法,引入tls確實是為實現類似應用做好了封裝。

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-10 09:02 by cexer
@www.helpsoff.com.cn
這個"/MT"應該指的鏈接是微軟運行時庫,C運行時庫。C++標準庫對包括map在內的容器在多線程環境當中的情況沒有采取任何的保護措施。

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-10 14:09 by www.helpsoff.com.cn
對頭,/MT是指連接微軟的runtime lib,相對于標準庫來將,這個庫的實現是支持多線程的。不過博主說的對,連接這個庫并不能保證map是線程安全了。獻丑了...

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-10 22:53 by 夢在天涯
TlsObject<***> 這個東東哪里來的那,TLS倒是蠻好用的哦!

http://m.shnenglu.com/mzty/archive/2007/08/01/28892.html

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2008-07-10 23:22 by cexer
@夢在天涯
應該是TlsSingelton,我寫錯了哈,謝謝提醒。

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2009-08-31 22:42 by stidio
這樣寫,用處不大,其實線程局部化本身用處就不大
如果這樣寫,同一個線程中持有的是不同的映射實例,而很多情況(不僅僅是窗口映射),這樣做的目的,是為了根據一個index獲得一個結果,也就是查詢;
如果這樣最,對于跨線程查詢,你必須破壞你的設計;

不知道是不是我理解的問題,單件模式的引出,是為了確定資源的唯一性;而你的這個恰恰不是;例如:
張三,李四的老板是王五,那王五對于張三,李四來說,是他的"單件"
張7,張8的爸爸是張9,那張9是單件

而你卻構建了一個,張9和王五的集合,說這是另外4個人的單件,這并不符合唯一性條件;

關于單件模型的多線程問題,其實單件本身沒多線程問題,多線程問題的引入是在對單件對象的使用上;如果說單件存在著多線程問題,那也僅僅需要在創建時鎖定(比如說2個線程同時獲得,都為空,創建2次;這樣需要在創建時鎖定,并做二次判斷,如
if(xx == 0) {
lock();
if(xx == 0)
xx = new XX;
....
}
而其實大多數情況不需要這樣來折騰;


超哥不錯哈,出去后的確進步了很多;

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2009-09-01 12:15 by cexer
@stidio
這個設計是設計給不跨線程的應用的,主要考慮在這種應用下,如果線程太多,都去查詢同一個全局的東西,大多數線程都一直處于等待資源的狀態,比較浪費CPU時間。
這是在公司時寫的哈,出來后倒沒寫了,感覺是人越來越懶了,寫程序越來越沒激情

# re: 線程相關的單件模式(Thread-Specific Singelton)  回復  更多評論   

2010-05-12 16:10 by ZeroQ
#define theWindowMap (WindowMapImpl::tlsInstance()->theWindowMapImpl())
上面一行中,WindowMapImpl::tlsInstance()返回的是WindowMap實例,而WindowMap并沒有theWindowMapImpl()方法,不知道這樣是如何實現的。請教嘍。。。
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲高清在线观看| 久久久久一区二区三区四区| 老司机精品导航| 久久久久久网| 欧美91大片| 欧美日韩一区二区免费在线观看 | 亚洲欧美不卡| 欧美在线免费一级片| 久久久久成人精品免费播放动漫| 欧美一级午夜免费电影| 久久久免费观看视频| 欧美高清hd18日本| 一区二区欧美在线| 久久久精品久久久久| 欧美国产乱视频| 国产午夜精品全部视频在线播放| 亚洲福利视频一区二区| 亚洲一二三区在线| 欧美成人视屏| 亚洲午夜精品久久久久久浪潮| 久久精品在线播放| 欧美日韩免费观看中文| 一区在线播放视频| 欧美一区二区三区视频免费播放| 欧美福利在线观看| 欧美一进一出视频| 欧美精品一线| 亚洲电影免费观看高清完整版| 中文有码久久| 欧美激情亚洲精品| 欧美在线一二三四区| 欧美日精品一区视频| 精品91在线| 欧美一区二区三区婷婷月色| 亚洲片区在线| 欧美在线视频一区二区三区| 国产精品一区在线观看| 欧美成人在线免费观看| 欧美精品一区在线播放| 国内精品一区二区三区| 亚洲女同在线| 99精品欧美一区二区三区| 蜜臀a∨国产成人精品| 国产一区二区三区日韩欧美| 亚洲一区二区在线免费观看| 亚洲激情影院| 欧美xxxx在线观看| 尤物在线精品| 久久人人97超碰人人澡爱香蕉| 亚洲一区二区精品在线观看| 欧美日韩高清在线| 9l国产精品久久久久麻豆| 欧美国产日韩一二三区| 久久综合久久综合久久综合| 国产一区二区三区在线免费观看 | 亚洲自拍电影| 一本久道久久综合中文字幕| 欧美激情1区| 亚洲精品在线观看视频| 亚洲二区视频| 欧美女同视频| 亚洲午夜精品在线| 亚洲一区二区免费在线| 国产精自产拍久久久久久蜜| 欧美专区在线| 久久久久久亚洲综合影院红桃| 激情婷婷久久| 亚洲国产精品电影在线观看| 欧美久久久久久| 亚洲欧美一区二区激情| 欧美一区二区大片| 在线播放不卡| 亚洲精品乱码久久久久久久久| 欧美日本在线视频| 午夜日韩av| 久久先锋资源| 99视频精品免费观看| 在线亚洲观看| 狠狠入ady亚洲精品经典电影| 欧美黄色成人网| 欧美午夜大胆人体| 久久人人爽国产| 欧美日韩高清一区| 久久激情综合网| 欧美精品七区| 久久久噜噜噜| 欧美日韩aaaaa| 久久久www成人免费毛片麻豆| 老鸭窝91久久精品色噜噜导演| 夜夜精品视频一区二区| 午夜精品久久久久影视| 亚洲激情在线视频| 午夜日韩在线| 欧美精选在线| 先锋资源久久| 欧美高清不卡| 久久青草久久| 欧美午夜寂寞影院| 欧美成人精品不卡视频在线观看| 欧美日韩国产高清| 美女成人午夜| 国产美女精品免费电影| 亚洲韩国青草视频| 韩国v欧美v日本v亚洲v | 久热精品在线| 欧美亚洲系列| 欧美日韩国产成人| 欧美高清视频一二三区| 国产欧美日韩视频| 亚洲精品美女91| 1769国产精品| 午夜欧美精品| 亚洲综合激情| 欧美激情aaaa| 欧美1区视频| 国产一区二区日韩精品| 在线亚洲电影| 国产精品99久久久久久www| 久久亚洲欧美| 久久亚洲精品网站| 国产一区二区三区黄| 亚洲香蕉伊综合在人在线视看| 亚洲日韩视频| 麻豆精品视频| 欧美激情成人在线| 亚洲日韩欧美视频一区| 免费成人av在线| 欧美电影资源| 亚洲黄色有码视频| 久久综合九色99| 欧美91视频| 亚洲第一中文字幕| 欧美xxxx在线观看| 欧美激情一区二区三区全黄| 黄色成人91| 久久亚洲精品中文字幕冲田杏梨| 久久噜噜亚洲综合| 亚洲高清不卡在线观看| 久久在线视频在线| 欧美激情中文不卡| 亚洲欧洲美洲综合色网| 美女久久一区| 亚洲激情视频在线观看| 一区二区激情| 欧美视频在线观看免费| 亚洲视频一起| 欧美在线www| 黄色精品网站| 免费高清在线视频一区·| 亚洲激情视频在线观看| 日韩一区二区精品视频| 欧美日韩综合在线| 亚洲欧美制服另类日韩| 久久国产视频网| 一区二区三区我不卡| 欧美激情综合五月色丁香小说| 亚洲精品国精品久久99热| 亚洲一区二区av电影| 国产伦精品一区二区| 久久精品人人做人人综合| 欧美成人一区二区三区片免费| 欧美视频中文字幕在线| 99热免费精品在线观看| 国产午夜精品全部视频播放 | 欧美视频在线观看一区二区| 亚洲一区二区日本| 免费看的黄色欧美网站| 夜色激情一区二区| 国产欧美91| 欧美精品午夜| 欧美一进一出视频| 国一区二区在线观看| 欧美成人亚洲成人| 亚洲性线免费观看视频成熟| 久久影音先锋| 亚洲一区二区四区| 一区二区在线免费观看| 欧美手机在线视频| 麻豆精品一区二区综合av| 正在播放亚洲| 亚洲国产裸拍裸体视频在线观看乱了| 亚洲综合欧美日韩| 亚洲国产另类精品专区| 国产精品久久久久一区二区三区共 | 久久久综合免费视频| 日韩午夜电影av| 久久综合久色欧美综合狠狠| 一区二区三区四区国产| 一区三区视频| 国产欧美日韩一区| 欧美日韩激情小视频| 久久久久久一区二区| 一区二区三区视频观看| 欧美激情中文不卡| 久色婷婷小香蕉久久| 先锋影音网一区二区| 亚洲一区www| 中文国产成人精品| 99www免费人成精品| 亚洲精品国精品久久99热一|