很多人對CRITICAL_SECTION的理解是錯誤的创译,認(rèn)為CRITICAL_SECTION是鎖定了資源,其實墙基,CRITICAL_SECTION是不能夠“鎖定”資源的软族,它能夠完成的功能,是同步不同線程的代碼段残制。簡單說立砸,當(dāng)一個線程執(zhí)行了 EnterCritialSection之后,cs里面的信息便被修改了初茶,以指明哪一個線程占用了它颗祝。而此時,并沒有任何資源被“鎖定”恼布。不管什么資源螺戳,其它線程都還是可以訪問的(當(dāng)然,執(zhí)行的結(jié)果可能是錯誤的)折汞。只不過倔幼,在這個線程尚未執(zhí)行LeaveCriticalSection之前,其它線程碰到 EnterCritialSection語句的話爽待,就會處于等待狀態(tài)损同,相當(dāng)于線程被掛起了。 這種情況下鸟款,就起到了保護(hù)共享資源的作用膏燃。也正由于CRITICAL_SECTION是這樣發(fā)揮作用的,所以何什,必須把每一個線程中訪問共享資源的語句都放在EnterCritialSection和LeaveCriticalSection之間蹄梢。這是初學(xué)者很容易忽略的地方。
當(dāng)然富俄,上面說的都是對于同一個CRITICAL_SECTION而言的。 如果用到兩個CRITICAL_SECTION而咆,比如說:第一個線程已經(jīng)執(zhí)行了EnterCriticalSection(&cs)并且還沒有執(zhí)行 LeaveCriticalSection(&cs)霍比,這時另一個線程想要執(zhí)行EnterCriticalSection(&cs2),這種情況是可以的(除非cs2已經(jīng)被第三個線程搶先占用了)暴备。 這也就是多個CRITICAL_SECTION實現(xiàn)同步的思想悠瞬。
比如說我們定義了一個共享資源dwTime[100],兩個線程ThreadFuncA和ThreadFuncB都對它進(jìn)行讀寫操作。當(dāng)我們想要保證 dwTime[100]的操作完整性浅妆,即不希望寫到一半的數(shù)據(jù)被另一個線程讀取望迎,那么用CRITICAL_SECTION來進(jìn)行線程同步如下:
第一個線程函數(shù):
DWORD WINAPI ThreadFuncA(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
寫出這個函數(shù)之后,很多初學(xué)者都會錯誤地以為凌外,此時cs對dwTime進(jìn)行了鎖定操作辩尊,dwTime處于cs的保護(hù)之中。一個“自然而然”的想法就是——cs和dwTime一一對應(yīng)上了康辑。 這么想摄欲,就大錯特錯了。dwTime并沒有和任何東西對應(yīng)疮薇,它仍然是任何其它線程都可以訪問的胸墙。如果你像如下的方式來寫第二個線程,那么就會有問題:
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
...
// 操作dwTime
...
return 0;
}
當(dāng)線程ThreadFuncA執(zhí)行了EnterCriticalSection(&cs)按咒,并開始操作dwTime[100]的時候迟隅,線程ThreadFuncB可能隨時醒過來,也開始操作dwTime[100]励七,這樣智袭,dwTime[100]中的數(shù)據(jù)就被破壞了。為了讓 CRITICAL_SECTION發(fā)揮作用呀伙,我們必須在訪問dwTime的任何一個地方都加上 EnterCriticalSection(&cs)和LeaveCriticalSection(&cs)語句补履。所以,必須按照下面的方式來寫第二個線程函數(shù):
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
這樣剿另,當(dāng)線程ThreadFuncB醒過來時箫锤,它遇到的第一個語句是EnterCriticalSection(&cs),這個語句將對cs變量進(jìn)行訪問雨女。如果這個時候第一個線程仍然在操作dwTime[100]谚攒,cs變量中包含的值將告訴第二個線程,已有其它線程占用了cs氛堕。因此馏臭,第二個線程的 EnterCriticalSection(&cs)語句將不會返回,而處于掛起等待狀態(tài)讼稚。直到第一個線程執(zhí)行了 LeaveCriticalSection(&cs)括儒,第二個線程的EnterCriticalSection(&cs)語句才會返回,并且繼續(xù)執(zhí)行下面的操作锐想。
這個過程實際上是通過限制有且只有一個函數(shù)進(jìn)入CriticalSection變量來實現(xiàn)代碼段同步的帮寻。簡單地說,對于同一個CRITICAL_SECTION赠摇,當(dāng)一個線程執(zhí)行了EnterCriticalSection而沒有執(zhí)行 LeaveCriticalSection的時候固逗,其它任何一個線程都無法完全執(zhí)行EnterCriticalSection而不得不處于等待狀態(tài)浅蚪。
再次強(qiáng)調(diào)一次,沒有任何資源被“鎖定”烫罩,CRITICAL_SECTION這個東東不是針對于資源的惜傲,而是針對于不同線程間的代碼段的!我們能夠用它來進(jìn)行所謂資源的“鎖定”贝攒,其實是因為我們在任何訪問共享資源的地方都加入了EnterCriticalSection和 LeaveCriticalSection語句盗誊,使得同一時間只能夠有一個線程的代碼段訪問到該共享資源而已(其它想訪問該資源的代碼段不得不等待)。如果是兩個CRITICAL_SECTION饿这,就以此類推浊伙。
再舉個極端的例子,可以幫助你理解CRITICAL_SECTION這個東東:
第一個線程函數(shù):
DWORD WINAPI ThreadFuncA(LPVOID lp)
{
EnterCriticalSection(&cs);
for(int i=0;i <1000;i++)
Sleep(1000);
LeaveCriticalSection(&cs);
return 0;
}
第二個線程函數(shù):
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
EnterCriticalSection(&cs);
index=2;
LeaveCriticalSection(&cs);
return 0;
}
這種情況下长捧,第一個線程中間總共Sleep了1000秒鐘嚣鄙!它顯然沒有對任何資源進(jìn)行什么“有意識”的保護(hù);而第二個線程是要訪問資源index的串结,但是由于第一個線程占用了cs哑子,一直沒有Leave,而導(dǎo)致第二個線程不得不登上1000秒鐘……第二個線程肌割,真是可憐哪卧蜓。。把敞。
這個應(yīng)該很說明問題了弥奸,你會看到第二個線程在1000秒鐘之后開始執(zhí)行index=2這個語句。也就是說奋早,CRITICAL_SECTION其實并不理會你關(guān)心的具體共享資源盛霎,它只按照自己的規(guī)律辦事~