您好,登錄后才能下訂單哦!
這篇文章主要講解了“CRITICAL_SECTION用法實例介紹”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“CRITICAL_SECTION用法實例介紹”吧!
很多人對CRITICAL_SECTION的理解是錯誤的,認為CRITICAL_SECTION是鎖定了資源,其實,CRITICAL_SECTION是不能夠“鎖定”資源的,它能夠完成的功能,是同步不同線程的代碼段。簡單說,當一個線程執行了EnterCritialSection之后,cs里面的信息便被修改,以指明哪一個線程占用了它。而此時,并沒有任何資源被“鎖定”。不管什么資源,其它線程都還是可以訪問的(當然,執行的結果可能是錯誤的)。只不過,在這個線程尚未執行LeaveCriticalSection之前,其它線程碰到EnterCritialSection語句的話,就會處于等待狀態,相當于線程被掛起了。 這種情況下,就起到了保護共享資源的作用。
也正由于CRITICAL_SECTION是這樣發揮作用的,所以,必須把每一個線程中訪問共享資源的語句都放在EnterCritialSection和LeaveCriticalSection之間。這是初學者很容易忽略的地方。
當然,上面說的都是對于同一個CRITICAL_SECTION而言的。 如果用到兩個CRITICAL_SECTION,比如說:
第一個線程已經執行了EnterCriticalSection(&cs)并且還沒有執行LeaveCriticalSection(&cs),這時另一個線程想要執行EnterCriticalSection(&cs2),這種情況是可以的(除非cs2已經被第三個線程搶先占用了)。這也就是多個CRITICAL_SECTION實現同步的思想。
比如說我們定義了一個共享資源dwTime[100],兩個線程ThreadFuncA和ThreadFuncB都對它進行讀寫操作。當我們想要保證 dwTime[100]的操作完整性,即不希望寫到一半的數據被另一個線程讀取,那么用CRITICAL_SECTION來進行線程同步如下:
第一個線程函數:
DWORD WINAPI ThreadFuncA(LPVOID lp) { EnterCriticalSection(&cs); ... // 操作dwTime ... LeaveCriticalSection(&cs); return 0; }
寫出這個函數之后,很多初學者都會錯誤地以為,此時cs對dwTime進行了鎖定操作,dwTime處于cs的保護之中。一個“自然而然”的想法就是——cs和dwTime一一對應上了。這么想,就大錯特錯了。dwTime并沒有和任何東西對應,它仍然是任何其它線程都可以訪問的。
如果你像如下的方式來寫第二個線程,那么就會有問題:
DWORD WINAPI ThreadFuncB(LPVOID lp) { ... // 操作dwTime ... return 0; }
當線程ThreadFuncA執行了EnterCriticalSection(&cs),并開始操作dwTime[100]的時候,線程ThreadFuncB可能隨時醒過來,也開始操作dwTime[100],這樣,dwTime[100]中的數據就被破壞了。
為了讓 CRITICAL_SECTION發揮作用,我們必須在訪問dwTime的任何一個地方都加上 EnterCriticalSection(&cs)和LeaveCriticalSection(&cs)語句。所以,必須按照下面的方式來寫第二個線程函數:
DWORD WINAPI ThreadFuncB(LPVOID lp) { EnterCriticalSection(&cs); ... // 操作dwTime ... LeaveCriticalSection(&cs); return 0; }
這樣,當線程ThreadFuncB醒過來時,它遇到的第一個語句是EnterCriticalSection(&cs),這個語句將對cs變量進行訪問。如果這個時候第一個線程仍然在操作dwTime[100],cs變量中包含的值將告訴第二個線程,已有其它線程占用了cs。因此,第二個線程的 EnterCriticalSection(&cs)語句將不會返回,而處于掛起等待狀態。直到第一個線程執行了 LeaveCriticalSection(&cs),第二個線程的EnterCriticalSection(&cs)語句才會返回,并且繼續執行下面的操作。
這個過程實際上是通過限制有且只有一個函數進入CriticalSection變量來實現代碼段同步的。簡單地說,對于同一個CRITICAL_SECTION,當一個線程執行了EnterCriticalSection而沒有執行 LeaveCriticalSection的時候,其它任何一個線程都無法完全執行EnterCriticalSection而不得不處于等待狀態。
再次強調一次,沒有任何資源被“鎖定”,CRITICAL_SECTION這個東東不是針對于資源的,而是針對于不同線程間的代碼段的!我們能夠用它來進行所謂資源的“鎖定”,其實是因為我們在任何訪問共享資源的地方都加入了EnterCriticalSection和 LeaveCriticalSection語句,使得同一時間只能夠有一個線程的代碼段訪問到該共享資源而已(其它想訪問該資源的代如果是兩個CRITICAL_SECTION,就以此類推。碼段不得不等待)。
如果是兩個CRITICAL_SECTION,就以此類推。
再舉個極端的例子,可以幫助你理解CRITICAL_SECTION這個東東:
第一個線程函數:
DWORD WINAPI ThreadFuncA(LPVOID lp) { EnterCriticalSection(&cs); for(int i=0;i <1000;i++) Sleep(1000); LeaveCriticalSection(&cs); return 0; }
第二個線程函數:
DWORD WINAPI ThreadFuncB(LPVOID lp) { EnterCriticalSection(&cs); index=2; LeaveCriticalSection(&cs); return 0; }
這種情況下,第一個線程中間總共Sleep了1000秒鐘!它顯然沒有對任何資源進行什么“有意識”的保護;而第二個線程是要訪問資源index的,但是由于第一個線程占用了cs,一直沒有Leave,而導致第二個線程不得不等上1000秒鐘……
第二個線程,真是可憐啊!
這個應該很說明問題了,你會看到第二個線程在1000秒鐘之后開始執行index=2這個語句。也就是說,CRITICAL_SECTION其實并不理會你關心的具體共享資源,它只按照自己的規律辦事~
感謝各位的閱讀,以上就是“CRITICAL_SECTION用法實例介紹”的內容了,經過本文的學習后,相信大家對CRITICAL_SECTION用法實例介紹這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。