很多人對CRITICAL_SECTION的理解是錯誤的，認(rèn)為CRITICAL_SECTION是鎖定了資源，其實(shí)，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é)者很容易忽略的地方。

第一個線程已經(jīng)執(zhí)行了EnterCriticalSection(&cs)并且還沒有執(zhí)行LeaveCriticalSection(&cs)，這時另一個線程想要執(zhí)行EnterCriticalSection(&cs2)，這種情況是可以的（除非cs2已經(jīng)被第三個線程搶先占用了）。這也就是多個CRITICAL_SECTION實(shí)現(xiàn)同步的思想。

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í)際上是通過限制有且只有一個函數(shù)進(jìn)入CriticalSection變量來實(shí)現(xiàn)代碼段同步的。簡單地說，對于同一個CRITICAL_SECTION，當(dāng)一個線程執(zhí)行了EnterCriticalSection而沒有執(zhí)行 LeaveCriticalSection的時候，其它任何一個線程都無法完全執(zhí)行EnterCriticalSection而不得不處于等待狀態(tài)。
      再次強(qiáng)調(diào)一次，沒有任何資源被“鎖定”，CRITICAL_SECTION這個東東不是針對于資源的，而是針對于不同線程間的代碼段的！我們能夠用它來進(jìn)行所謂資源的“鎖定”，其實(shí)是因為我們在任何訪問共享資源的地方都加入了EnterCriticalSection和 LeaveCriticalSection語句，使得同一時間只能夠有一個線程的代碼段訪問到該共享資源而已（其它想訪問該資源的代如果是兩個CRITICAL_SECTION，就以此類推。碼段不得不等待）。如果是兩個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其實(shí)并不理會你關(guān)心的具體共享資源，它只按照自己的規(guī)律辦事~