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

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>
            亚洲免费高清| 亚洲一区二区高清视频| 国产精品视频网站| 亚洲小说欧美另类婷婷| 日韩视频三区| 国产欧美亚洲视频| 午夜一区二区三视频在线观看| 亚洲女ⅴideoshd黑人| 国产精品爽爽爽| 欧美一级二级三级蜜桃| 亚洲影音一区| 国产亚洲精品美女| 老司机午夜精品| 玖玖国产精品视频| 欧美一区二区免费观在线| 久久国产欧美| 美日韩精品免费| 亚洲小说欧美另类社区| 亚洲欧美日韩中文播放| 欧美国产精品中文字幕| 日韩视频―中文字幕| 亚洲第一精品电影| 欧美日韩人人澡狠狠躁视频| 亚洲精品中文字幕女同| 亚洲激情视频| 激情成人在线视频| 制服丝袜亚洲播放| 亚洲激情第一区| 亚洲综合999| 欧美伊人影院| 欧美性猛片xxxx免费看久爱 | 国产女主播一区二区| 99精品视频免费观看| 蜜臀久久久99精品久久久久久| 99国产精品久久久久久久| 久久精品91| 麻豆精品精品国产自在97香蕉| 欧美顶级少妇做爰| 美日韩在线观看| 精品动漫一区二区| 久久亚洲私人国产精品va| 美女露胸一区二区三区| 国产精品视频xxx| 一区二区三区免费网站| 亚洲欧洲日韩在线| 欧美精品一区在线| 亚洲成色www8888| 亚洲国产视频直播| 欧美激情第1页| 欧美一级久久| 精品二区视频| 蜜臀a∨国产成人精品| 在线一区二区三区四区五区| 你懂的亚洲视频| 欧美一区在线看| 亚洲欧美日韩国产综合| 一本色道久久99精品综合| 9国产精品视频| 亚洲日韩中文字幕在线播放| 国产曰批免费观看久久久| 国产一级精品aaaaa看| 国内精品一区二区| 亚洲欧洲另类| 99re66热这里只有精品4| 日韩视频在线播放| 一区二区不卡在线视频 午夜欧美不卡在 | 99re热这里只有精品免费视频| 国内精品久久久久影院优 | 一本久久综合亚洲鲁鲁五月天| 欧美jizzhd精品欧美巨大免费| 亚洲婷婷免费| 欧美日韩免费在线观看| 国产精品青草久久| 午夜精品久久| 欧美亚洲自偷自偷| 亚洲成色999久久网站| 裸体一区二区| 欧美亚洲网站| 免费一区视频| 午夜精品久久久久久久男人的天堂| 久久久午夜电影| 欧美日韩国产大片| 国产亚洲欧美另类一区二区三区| 亚洲国产成人精品久久| 午夜日韩激情| 亚洲免费一级电影| 国产精品日韩高清| 亚洲深夜福利在线| 亚洲麻豆国产自偷在线| 欧美黄色视屏| 中文久久乱码一区二区| 欧美国产精品日韩| 欧美日韩一区二区在线| 正在播放欧美一区| 午夜激情久久久| 好吊妞**欧美| 亚洲国产精品电影| 欧美精品成人| 午夜精品久久久久久| 亚洲一区二区不卡免费| 亚洲视屏一区| 亚洲韩国精品一区| 国产精品视频免费观看| 欧美激情按摩| 先锋a资源在线看亚洲| 国产欧美日本一区视频| 久久久精品性| 欧美福利在线观看| 亚洲一区二区三区久久| 国产亚洲激情视频在线| 国产一区二区主播在线| 国产视频一区在线观看| 国产伦理精品不卡| 激情欧美一区二区| 欧美激情第六页| 欧美午夜不卡影院在线观看完整版免费| 亚洲国产精品一区制服丝袜| 久久久99精品免费观看不卡| 久久一区中文字幕| 亚洲自拍16p| 欧美日韩精品一区二区| 久久先锋影音| 国产欧美日韩激情| 亚洲私人黄色宅男| 中文欧美日韩| 欧美国产日本高清在线| 欧美专区中文字幕| 国产精品第2页| 亚洲欧洲一区二区三区久久| 国产精品a久久久久久| 99热这里只有成人精品国产| 亚洲人成网在线播放| 久久国产精彩视频| 欧美主播一区二区三区美女 久久精品人 | 欧美高清在线一区| 国产精品私拍pans大尺度在线 | 欧美国产大片| 亚洲国产日韩综合一区| 在线看片一区| 久久精品国产一区二区电影| 欧美一级一区| 在线播放豆国产99亚洲| 欧美在线一级视频| 亚洲欧洲日本在线| 欧美综合国产| 亚洲国产欧美精品| 久久国产日韩| 亚洲卡通欧美制服中文| 亚洲一区二区三区久久| 黄色成人在线网站| 欧美丰满少妇xxxbbb| 亚洲欧美第一页| 欧美顶级艳妇交换群宴| 亚洲一区二区三区国产| 国内精品视频在线观看| 欧美日韩亚洲一区二区| 亚洲精品美女在线| 欧美一区二区三区精品| 国产主播精品| 国产精品国产三级国产专区53| 久久免费精品日本久久中文字幕| 99视频超级精品| 美女诱惑黄网站一区| 亚洲夜间福利| 一本一本a久久| 在线观看日韩av| 激情六月婷婷久久| 国产精品视频福利| 欧美精品一区二区高清在线观看| 久久久精品国产免大香伊| 亚洲一区二区精品在线| 欧美激情一区二区三区| 久久精品一本久久99精品| 国产精品美女一区二区在线观看| 亚洲激情成人网| 女仆av观看一区| 蜜桃精品一区二区三区| 亚洲小说区图片区| 久久国产精品99国产精| 日韩视频一区二区| 久久久国产一区二区三区| 一本色道久久综合| 久久国产精品免费一区| 一本久道久久综合婷婷鲸鱼 | 亚洲国产精品悠悠久久琪琪| 国产精品另类一区| 欧美激情第一页xxx| 国产精品久久久久久模特| 欧美成人情趣视频| 国产精品伊人日日| 亚洲电影一级黄| 国产一区二区中文| 亚洲欧洲在线一区| 精品av久久707| 午夜视黄欧洲亚洲| 亚洲综合色在线| 欧美日韩免费看| 亚洲高清自拍| 亚洲国产清纯| 久久综合网色—综合色88|