揭示同步塊索引（上）：從lock開始

作者: 橫刀天笑來源: 博客園發布時間: 2009-08-24 10:06 閱讀: 2496 次推薦: 0 原文鏈接 [收藏]

大家都知道引用類型對象除實例字段的開銷外，還有兩個字段的開銷：類型指針和同步塊索引（SyncBlockIndex）。同步塊索引這個東西比起它的兄弟類型指針更少受人關注，顯得有點冷落，其實此兄功力非凡，在CLR里可謂叱咤風云，很多功能都要借助它來實現。接下來我會用三篇來介紹同步塊索引在.NET中的所作所為。
既然本章副標題是從lock開始，那我就舉幾個lock的示例：

代碼1

public class Singleton

{

    private static object lockHelper = new object();

    private static Singleton _instance = null;

    public static Singleton Instance

    {

        get

        {

            lock(lockHelper)

            {

                if(_instance == null)

                    _instance = new Singleton();

            }

            return _instance;

        }

    }

}

代碼2

public class Singleton

{

    private static Singleton _instance = null;

    public static Singleton Instance

    {

        get

        {

            object lockHelper = new object();

            lock(lockHelper)

            {

                if(_instance==null)

                    _instance = new Singleton();

            }

            return _instance;

        }

    }

}

代碼3

public class Singleton

{

    private static Singleton _instance = null;

    public static Singleton Instance

    {

        get

        {

            lock(typeof(Singleton))

            {

                if(_instance==null)

                    _instance = new Singleton();

            }

            return_instance;

        }

    }

}

代碼4

public void DoSomething()

{

    lock(this)

    {

        //dosomething

    }

}

上面四種代碼，對于加鎖的方式來說（不討論其他）哪一種是上上選？對于這個問題的答案留在本文最后解答。

讓我們先來看看在Win32的時代，我們如何做到CLR中的lock的效果。在Win32時，Windows為我們提供了一個CRITICAL_SECTION結構，看看上面的單件模式，如果使用CRITICAL_SECTION的方式如何實現？

class Singleton

{

    private:

        CRITICAL_SECTIONg_cs;

        static Singleton _instance = NULL;

    public:

        Singleton()

        {

            InitializeCriticalSection(&g_cs);

        }

        static Singleton GetInstance()

        {

            EnterCriticalSection(&g_cs);

            if(_instance!=NULL)

                _instance=newSingleton();

            LeaveCriticalSection(&g_cs);

            return_instance;

        }

        ~Singleton()

        {

            DeleteCriticalSection(&g_cs);

        }

}

Windows提供四個方法來操作這個CRITICAL_SECTION，在構造函數里我們使用InitializeCriticalSection這個方法初始化這個結構，它知道如何初始化CRITICAL_SECTION結構的成員，當我們要進入一個臨界區訪問共享資源時，我們使用EnterCriticalSection方法，該方法首先會檢查CRITICAL_SECTION的成員，檢查是否已經有線程進入了臨界區，如果有，則線程會等待，否則會設置CRITICAL_SECTION的成員，標識出本線程進入了臨界區。當臨界區操作結束后，我們使用LeaveCriticalSection方法標識線程離開臨界區。在Singleton類的析構函數里，我們使用DeleteCriticalSection方法銷毀這個結構。整個過程就是如此。
我們可以在WinBase.h里找到CRITICAL_SECTION的定義：

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;

可以看到，CRITICAL_SECTION實際上就是RTL_CRITICAL_SECTION，而RTL_CRITICAL_SECTION又是在WinNT.h里定義的：

typedef struct _RTL_CRITICAL_SECTION{

PRTL_CRITICAL_SECTION_DEBUGDebugInfo;

//

//Thefollowingthreefieldscontrolenteringandexitingthecritical

//sectionfortheresource

//

LONG LockCount;

LONG RecursionCount;

HANDLE OwningThread;//fromthethread'sClientId->UniqueThread

HANDLE LockSemaphore;

ULONG _PTRSpinCount;//forcesizeon64-bitsystemswhenpacked

}RTL_CRITICAL_SECTION,*PRTL_CRITICAL_SECTION;

從上面的定義和注釋，聰明的你肯定知道Windows API提供的這幾個方法是如何操作CRITICAL_SECTION結構的吧。在這里我們只需要關注OwningThread成員，當有線程進入臨界區的時候，這個成員就會指向當前線程的句柄。

說了這么多，也許有人已經厭煩了，不是說好說lock么，怎么說半天Win32 API呢，實際上CLR的lock與Win32 API實現方式幾乎是一樣的。但CLR并沒有提供CRITICAL_SECTION結構，不過CLR提供了同步塊，CLR還提供了System.Threading.Monitor類。

實際上使用lock的方式，與下面的代碼是等價的：

try{ 

    Monitor.Enter(obj); 

    //… 

}finally{ 

    Monitor.Exit(obj); 

}

（以下內容只限制在本文，為了簡單，有的說法很片面，更詳細的內容會在后面兩篇里描述）

當CLR初始化的時候，CLR會初始化一個SyncBlock的數組，當一個線程到達Monitor.Enter方法時，該線程會檢查該方法接受的參數的同步塊索引，默認情況下對象的同步塊索引是一個負數(實際上并不是負數，我這里只是為了敘說方便)，那么表明該對象并沒有一個關聯的同步塊，CLR就會在全局的SyncBlock數組里找到一個空閑的項，然后將數組的索引賦值給該對象的同步塊索引，SyncBlock的內容和CRITICAL_SECTION的內容很相似，當Monitor.Enter執行時，它會設置SyncBlock里的內容，標識出已經有一個線程占用了，當另外一個線程進入時，它就會檢查SyncBlock的內容，發現已經有一個線程占用了，該線程就會等待，當Monitor.Exit執行時，占用的線程就會釋放SyncBlock，其他的線程可以進入操作了。

好了，有了上面的解釋，我們現在可以判斷本文前面給出的幾個代碼，哪一個是上上選呢？

對于代碼2，鎖定的對象是作為一個局部變量，每個線程進入的時候，鎖定的對象都會不一樣，它的SyncBlock每一次都是重新分配的，這個根本談不上什么鎖定不鎖定。

對于代碼3，一般說來應該沒有什么事情，但這個操作卻是很危險的，typeof(Singleton)得到的是Singleton的Type對象，所有Singleton實例的Type都是同一個，Type對象也是一個對象，它也有自己的SyncBlock，Singleton的Type對象的SyncBlock在程序中只會有一份，為什么說這種做法是危險的呢？如果在該程序中，其他毫不相干的地方我們也使用了lock(typeof(Singleton))，雖然它和這里的鎖定毫無關系，但是只要一個地方鎖定了，各個地方的線程都會在等待。

對于代碼4，實際上代碼4的性質和代碼3差不多，如果有一個地方使用了DoSomething方法所在類的實例進行lock，而且恰好如this是同一個實例，那么兩個地方就會互斥了。

由此看來只有代碼1是上上選，之所以是這樣，是因為代碼1將鎖定的對象作為私有字段，只有這個對象內部可以訪問，外部無法鎖定。上面只是從文字上敘說，也許你覺得證據不足，我們就搬來代碼作證。使用ILDasm反編譯上面單件模式的Instance屬性的代碼，其中一段IL代碼如下所示：

IL_0007:stloc.1

IL_0008:call void [mscorlib]System.Threading.Monitor::Enter(object)

IL_000d:nop

.try

{

    IL_000e:nop

    IL_000f:ldsfld class Singleton Singleton::_instance

    //….

    //…

}

finally

{

    IL_002b:ldloc.1

    IL_002c:call void [mscorlib]System.Threading.Monitor::Exit(object)

    IL_0031:nop

    IL_0032:endfinally

}

為了簡單，我省去了一部分代碼。但是很明顯，我們看到了System.Threading.Monitor.Enter和Exit。然后我們拿出Reflector看看這個Monitor到底是何方神圣。哎呀，發現Monitor.Enter和Monitor.Exit的代碼如下所示：

[MethodImpl(MethodImplOptions.InternalCall)]

public static extern void Enter(objectobj);

[MethodImpl(MethodImplOptions.InternalCall),ReliabilityContract(Consistency.WillNotCorruptState,Cer.Success)]

public static extern void Exit(objectobj);

只見方法使用了extern關鍵字，方法上面還標有[MethodImpl(MethodImplOptions.InternalCall)]這樣的特性，實際上這說明Enter和Exit的代碼是在內部C++的代碼實現的。只好拿出Rotor的代碼求助了，對于所有"內部實現"的代碼，我們可以在sscli20\clr\src\vm\ecall.cpp里找到映射：

FCFuncStart(gMonitorFuncs) 

FCFuncElement("Enter", JIT_MonEnter) 

FCFuncElement("Exit", JIT_MonExit) 

… 

FCFuncEnd()

原來Enter映射到JIT_MonEnter，一步步的找過去，我們最終到了這里：

Sscli20\clr\src\vm\jithelpers.cpp：

HCIMPL_MONHELPER(JIT_MonEnterWorker_Portable, Object* obj) 

{ 

    //省略大部分代碼 

    OBJECTREF objRef = ObjectToOBJECTREF(obj); 

    objRef->EnterObjMonitor(); 

} 

HCIMPLEND

objRef就是object的引用，EnterObjMonitor方法的代碼如下：

void EnterObjMonitor() 

{ 

    GetHeader()->EnterObjMonitor(); 

}

GetHeader()方法獲取對象頭ObjHeader，在ObjHeader里有對EnterObjMonitor()方法的定義：

void ObjHeader::EnterObjMonitor() 

{ 

    GetSyncBlock()->EnterMonitor(); 

}

GetSyncBlock()方法會獲取該對象對應的SyncBlock，在SyncBlock里有EnterMonitor方法的定義：

void EnterMonitor() 

{ 

    m_Monitor.Enter(); 

}

離核心越來越近了，m_Monitor是一個AwareLock類型的字段，看看AwareLock類內Enter方法的定義：

void AwareLock::Enter() 

{ 

    Thread* pCurThread = GetThread(); 

    for (;;) 

    { 

         volatile LONG state = m_MonitorHeld; 

        if (state == 0) 

        { 

            // Common case: lock not held, no waiters. Attempt to acquire lock by 

             // switching lock bit. 

            if (FastInterlockCompareExchange((LONG*)&m_MonitorHeld, 1, 0) == 0) 

            { 

                break; 

            } 

        } 

        else 

        { 

            // It's possible to get here with waiters but no lock held, but in this 

             // case a signal is about to be fired which will wake up a waiter. So 

             // for fairness sake we should wait too. 

             // Check first for recursive lock attempts on the same thread. 

             if (m_HoldingThread == pCurThread) 

             { 

                 goto Recursion; 

             } 

            // Attempt to increment this count of waiters then goto contention 

            // handling code. 

        if (FastInterlockCompareExchange((LONG*)&m_MonitorHeld, (state + 2), state) == state) 

        { 

             goto MustWait;  

        } 

    } 

} 

    // We get here if we successfully acquired the mutex. 

    m_HoldingThread = pCurThread; 

    m_Recursion = 1; 

    pCurThread->IncLockCount(); 

    return; 

MustWait: 

     // Didn't manage to get the mutex, must wait. 

    EnterEpilog(pCurThread); 

     return; 

    Recursion: 

     // Got the mutex via recursive locking on the same thread. 

    m_Recursion++; 

}

從上面的代碼我們可以看到，先使用GetThread()獲取當前的線程，然后取出m_MonitorHeld字段，如果現在沒有線程進入臨界區，則設置該字段的狀態，然后將m_HoldingThread設置為當前線程，從這一點上來這與Win32的過程應該是一樣的。如果從m_MonitorHeld字段看，有線程已經進入臨界區則分兩種情況：第一，是否已進入的線程如當前線程是同一個線程，如果是，則把m_Recursion遞加，如果不是，則通過EnterEpilog(pCurThread)方法，當前線程進入線程等待隊列。

通過上面的文字描述和代碼的跟蹤，在我們的大腦中應該有這樣一張圖了：