• <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>

            C++ Programmer

            天行健,君子以自強不息; 地勢坤,君子以厚德載物

            多線程中局部靜態(tài)變量初始化的陷阱

                C++當(dāng)中常常需要一個全局唯一的對象實例,這時候,我們就會想到單件模式。如何實現(xiàn)這一模式?全局變量當(dāng)然是一個簡單可行的方法,然而,這太丑陋。嗯,其實,丑陋倒也罷了,最嚴(yán)重的是它將引誘程序員濫用全局變量,這將導(dǎo)致維護(hù)的災(zāi)難。

                既然全局變量是可能有害的,那么,我們我們把它隱藏一下,放到某個類當(dāng)中去,作為類的靜態(tài)數(shù)據(jù)成員。這看上去不錯,我也這么認(rèn)為。當(dāng)我們只是簡單的需要一個全局對象時,這很好,而且足夠簡單。不過,天空中尚有一朵小小的烏云,讓我們來看一看它是什么。

                靜態(tài)成員變量的初始化,和全局對象一樣,實際上是在main函數(shù)進(jìn)入后,我們寫下的第一行代碼之前被執(zhí)行的。而且,我們知道那個著名的初始化順序不可靠的問題(跨編譯單元)。當(dāng)我的全局對象是一個復(fù)雜對象――這很常見,比如一個環(huán)境管理器――它甚至還需要復(fù)雜的裝配過程,我們需要考慮:構(gòu)建這個單件的時候,其對象都準(zhǔn)備好了嗎?如果我們不能確定,那么一個常見的措施是延遲單件對象的構(gòu)造――把它延遲到全局對象初始化結(jié)束以后怎么樣?這好像很容易實現(xiàn):

            SomeClass * SomeClass ::instance()
             
            static SomeClass inst;
             
            return &inst;
            }

            不錯吧?它不但可以延遲到全局對象初始化之后,甚至可以延遲到有人需要它的時候,才被構(gòu)造出來,隨需應(yīng)變,呵呵,是不是很帥?嗯,還有一點小問題,不僅存在對象初始化順序問題,析構(gòu)也同樣存在問題。局部靜態(tài)變量的析構(gòu),和全局對象一樣,是在main函數(shù)退出前進(jìn)行的,如果也要考慮順序問題的話...是不是有點麻煩呢?

                過度設(shè)計是一種罪,我是不是考慮的太復(fù)雜了?如果壓根就不需要考慮析構(gòu)順序,這是不是很完美的解決方案?沒那么簡單!非但不夠完美,而且,這里面仍然存在缺陷:當(dāng)我們運行在多線程環(huán)境的時候,靜態(tài)變量的初始化來實現(xiàn)單件,是不可靠的――直接的說,靜態(tài)變量有可能初始化多次!在作實驗之前,我們現(xiàn)分析一下靜態(tài)局部變量的實現(xiàn)方式,下面是前面instance實現(xiàn)的偽碼:

            if (!initialized){
             initialized 
            = true;
             
            new (&inst)SomeClass;
            }

            return &inst;

            每個靜態(tài)變量都會擁有自己的初始化與否的標(biāo)志,靜態(tài)變量初始化并不是一個原子操作,也沒有為多線程而設(shè)立互斥區(qū)(C++語言本身是沒有線程概念的),因此,我們要想實現(xiàn)多線程下的單件延遲創(chuàng)建,就不得不解決重復(fù)初始化的問題。至于如何實現(xiàn),實際上這方面的代碼很多了。一個顯然的方案是設(shè)立互斥區(qū),傳統(tǒng)的雙檢測技術(shù)可以有效解決這一問題――至少目前的C++是這樣,至于最近在csdn看到在Java中雙檢測失效的文章,我認(rèn)為應(yīng)該由Java語言負(fù)責(zé)。

                其實,局部靜態(tài)變量可能多次初始化,并不難理解,實踐上,也很少出嚴(yán)重的問題――出問題的條件還是挺苛刻的:多線程,不可多次初始化,恰好多個線程同時調(diào)用,恰好在if之后發(fā)生線程調(diào)度。很少出問題,不等于不出問題,特別的,對于廣泛使用的應(yīng)用程序來說,出錯概率就不是一點點了。寫這篇東西的原因,是今天在公司看到的一段代碼,作了標(biāo)識符替換:

            SomeClass * SomeClass::GetInstance(){
             
            static CLock g_lock;
             
            if (m_pInstance == NULL){
              g_lock.Lock();
              
            if (m_pInstance == NULL){
               m_pInstance 
            = new SomeClass;
              }

              g_lock.Unlock();
             }

             
            return m_pInstance;
            }

            就這段代碼,雖然知道用雙檢測,且不說Lock/Unlock可以更好的處理,static CLock g_lock根本就是錯誤。鎖本身可能被初始化多次,象這種資源類型的對象,多次構(gòu)造幾乎肯定會出錯的。而對于單件模式的實現(xiàn),我認(rèn)為,一般而言,Loki:: SingletonHolder會是一個好的選擇。

             

            本文出處:http://blog.csdn.net/wingfiring/archive/2005/10/09/498242.aspx

            posted on 2009-07-24 10:47 Saga 閱讀(4698) 評論(0)  編輯 收藏 引用 所屬分類: MultiTask

            導(dǎo)航

            <2009年7月>
            2829301234
            567891011
            12131415161718
            19202122232425
            2627282930311
            2345678

            統(tǒng)計

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            久久99热国产这有精品| 精品久久亚洲中文无码| 久久久久久免费视频| 国内精品久久久久影院免费| 99国产精品久久| 久久国产香蕉视频| 亚洲精品无码久久久久去q| 精品久久久久久国产91| 久久精品亚洲男人的天堂| 精品国产乱码久久久久久1区2区| 色播久久人人爽人人爽人人片AV| 久久久精品免费国产四虎| 国产精品免费看久久久香蕉| 色综合久久综合中文综合网 | 99久久无色码中文字幕| 青青草国产成人久久91网| 99久久国产宗和精品1上映 | 久久影院综合精品| 久久99国产精品久久99小说| 品成人欧美大片久久国产欧美| 国产一级持黄大片99久久| 久久国产精品99久久久久久老狼 | 国产亚洲美女精品久久久| 一级做a爰片久久毛片看看| 久久国产精品国产自线拍免费| 久久精品夜夜夜夜夜久久| 一级A毛片免费观看久久精品| 久久国产综合精品五月天| 精品久久一区二区三区| 国产福利电影一区二区三区久久久久成人精品综合 | 色妞色综合久久夜夜| 精品久久久久久亚洲精品 | 国产69精品久久久久APP下载| 无码任你躁久久久久久久| 久久99精品国产麻豆| 模特私拍国产精品久久| 97精品国产91久久久久久| 一级做a爰片久久毛片人呢| 国内精品九九久久精品| 精品国产福利久久久| 久久久久波多野结衣高潮|