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

            yehao's Blog

            CreateThread()、_beginthreadex()及、AfxBeginThread()函數(shù)的討論

            操作系統(tǒng)中線程是非常重要的概念,所以關(guān)于線程的創(chuàng)建常常有些困擾人的內(nèi)容。好像創(chuàng)建線程的函數(shù)很多,那么他們之間的有什么聯(lián)系與區(qū)別呢?正如題目給出的三個函數(shù)。今天看了看Windows核心編程,再找了一些網(wǎng)上的資料,在此想說說這些函數(shù)之間的關(guān)系和區(qū)別。如有不正確的地方,請各位不吝賜教。

                  首先,需要說明的是這三個函數(shù)都與CreateThread。CreateThread函數(shù)是Windows的一個API函數(shù),其具體的使用方法在 MSDN和《Windows核心編程》上都有詳細介紹。主要的作用是創(chuàng)建一個線程。_beginthreadex函數(shù)是C/C++運行庫提供的函數(shù),從 _beginthreadex函數(shù)的源代碼,可以看出它的主要動作是:增加了一個名為ptd的_ptiddata的結(jié)構(gòu)的處理,然后在調(diào)用CreateThread函數(shù)。_ptiddata是每個線程都擁有自己的專用的數(shù)據(jù)結(jié)構(gòu)。關(guān)于使用CreateThread代替_beginthreadex的結(jié)果以及可能出現(xiàn)的問題在《Windows核心編程》上講的很清楚: “也許你想知道,如果調(diào)用CreateThread,而不是調(diào)用C/C++運行期庫的_beginthreadex來創(chuàng)建新線程,將會發(fā)生什么情況。當一個線程調(diào)用要求_ptiddata結(jié)構(gòu)的C / C + +運行期庫函數(shù)時,將會發(fā)生下面的一些情況(大多數(shù)C / C + +運行期庫函數(shù)都是線程安全函數(shù),不需要該結(jié)構(gòu))。

                   首先, C / C + +運行期庫函數(shù)試圖(通過調(diào)用T l s G e t Va l u e )獲取線程的數(shù)據(jù)塊的地址。如果返回N U L L作為t i d d a t a塊的地址,調(diào)用線程就不擁有與該地址相關(guān)的_t i d d a t a塊。這時,C / C + +運行期庫函數(shù)就在現(xiàn)場為調(diào)用線程分配一個_t i d d a t a塊,并對它進行初始化。然后該_t i d d a t a塊(通過T l s S e t Va l u e)與線程相關(guān)聯(lián)。此時,只要線程在運行,該_t i d d a t a將與線程待在一起。這時,C / C + +運行期庫函數(shù)就可以使用線程的_t i d d a t a塊,而且將來被調(diào)用的所有C / C + +運行期函數(shù)也能使用_t i d d a t a塊。當然,這看來有些奇怪,因為線程運行時幾乎沒有任何障礙。不過,實際上還是存在一些問題。首先,如果線程使用C / C + +運行期庫的s i g n a l函數(shù),那么整個進程就會終止運行,因為結(jié)構(gòu)化異常處理幀尚未準備好。

                   第二,如果不是調(diào)用_ e n d t h r e a d e x來終止線程的運行,那么數(shù)據(jù)塊就不會被撤消,內(nèi)存泄漏就會出現(xiàn)(那么誰還為使用C r e a t e T h r e a d函數(shù)創(chuàng)建的線程來調(diào)用_ e n d t h r e a d e x呢?)。”對于上面所說的兩個問題:我也是有疑問的:使用CreateThread創(chuàng)建線程后,用CloseHandle函數(shù)關(guān)閉相應的線程句柄,不會對_ptiddata結(jié)構(gòu)進行釋放嗎?另外在網(wǎng)上看到一些關(guān)于這三個函數(shù)的討論如下: 一直對這三個創(chuàng)建線程的方法都搞不清楚,不知道在什么情況下該用那種方法,下面是從網(wǎng)上摘錄的一些帖子:

                   1、不要在一個MFC程序中使用_beginthreadex()或CreateThread()。這句話的意思是由于AfxBeginThread()是MFC封裝的啟動線程的函數(shù),里面包含了很多和MFC相關(guān)的啟動信息,而且封裝了一些常用的操作,使用起來也比較簡便。而用另外兩個函數(shù)就需要程序員對類型,安全性檢查進行更多的思考!

                   2、用_beginthreadex()函數(shù)應該是最佳選擇,因為_beginthreadex()函數(shù)是CRun-timeLibrary中的函數(shù),函數(shù)的參數(shù)和數(shù)據(jù)類型都是CRun-timeLibrary中的類型,這樣在啟動線程時就不需要進行Windows數(shù)據(jù)類型和CRun-timeLibrary中的數(shù)據(jù)類型之間的轉(zhuǎn)化。減低了線程啟動時的資源消耗和時間的消耗!

                  3、在C程序中,幾乎都要用到new和delete,難道只有使用_beginthreadex()?不,因為MFC也是C類庫(只不過是Microsoft的C類庫,不是標準的C類庫),在MFC中也封裝了new和delete兩中運算符,所以用到new和delete的地方不一定非要使用_beginthreadex()函數(shù),用其他兩個函數(shù)都可以!其實在程序中使用上面的哪個函數(shù)并不是絕對的,書的作者只不過是提了一個更佳的搭配方法,我在MFC程序中也經(jīng)常使用_beginthreadex()和CreateThread()這兩個函數(shù),運行的效果也沒有多大的區(qū)別,有的時候只是需要你額外的進行一些類型檢查和其他的一些轉(zhuǎn)化操作,其余沒有其他不妥! 創(chuàng)建線程只有一個方法是::CreateThread()。_beginthreadex()、AfxBeginThread()等內(nèi)部都是調(diào)用這個函數(shù)的,因為操作系統(tǒng)只提供這一個接口C靜態(tài)庫比WINDOWS出來還早,就別提多線程了,所以他對多線程的支持不是很好,但后悔也來不急,但也不能怪人家。

                  C運行庫_beginthreadex()。他經(jīng)過一些處理后,再調(diào)用CreateThread()如果要強制結(jié)束的話也最好用_endthreadex結(jié)束,因為他也要一些處理。 總結(jié)上面的內(nèi)容,當然《Windows核心編程》上面得說法是比較權(quán)威的。所以,在對線程的結(jié)構(gòu)、運行還不是很了解的時候最好還是按照書上的來。這樣能夠避免一些可能出現(xiàn)的莫名奇妙的錯誤,也省去的一些其他結(jié)構(gòu)處理的考慮。當你清楚地知道線程的結(jié)構(gòu)與運行機制,以及了解各個函數(shù)對CreateThread函數(shù)的封裝的時候,大概那時候就能夠應用自如了


            本文來自CSDN博客,轉(zhuǎn)載請標明出處:http://blog.csdn.net/haisujiang/archive/2009/05/30/4225109.aspx

            posted on 2011-04-25 13:49 厚積薄發(fā) 閱讀(398) 評論(0)  編輯 收藏 引用 所屬分類: Windows編程

            導航

            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            統(tǒng)計

            常用鏈接

            留言簿

            隨筆分類

            文章分類

            文章檔案

            搜索

            最新評論

            激情五月综合综合久久69| 久久精品国产亚洲αv忘忧草| 人妻系列无码专区久久五月天| 久久久久国产精品| 国产精品久久久久9999| 久久er99热精品一区二区| 久久精品国产清高在天天线| 午夜天堂av天堂久久久| 亚洲AV无一区二区三区久久| 一本久久a久久精品vr综合| 2021国内久久精品| 无码国产69精品久久久久网站| A级毛片无码久久精品免费| 久久久无码人妻精品无码| 99久久婷婷国产综合亚洲| 狠狠色丁香久久综合五月| 欧美精品一区二区精品久久| 国产叼嘿久久精品久久| 青草久久久国产线免观| 久久精品人人做人人爽电影| 久久精品中文无码资源站| 久久国产精品久久久| 久久婷婷人人澡人人| 久久精品国产亚洲αv忘忧草 | 狠狠色丁香久久婷婷综| 一本一道久久精品综合| 少妇被又大又粗又爽毛片久久黑人 | 国产精品青草久久久久福利99| 国产99久久九九精品无码| 日韩一区二区三区视频久久| 亚洲国产一成人久久精品| 91精品国产91久久久久福利| 国产综合精品久久亚洲| 亚洲人成网站999久久久综合 | 少妇精品久久久一区二区三区| 久久精品成人免费看| 久久精品桃花综合| 四虎国产精品免费久久5151| 久久久www免费人成精品| 91精品国产91久久久久久| 久久无码国产专区精品|