同步块索引syncblock

大家都知道引用类型对象除实例字段的开销外,还有两个字段的开销:类型指针和同步块索引(SyncBlockIndex)。同步块索引这个东西比起它的兄弟类型指针更少受人关注,显得有点冷落,其实此兄功力非凡,在CLR里可谓叱咤风云,很多功能都要借助它来实现。 接下来我会用三篇来介绍同步块索引在.NET中的所作所为。 
既然本章副标题是从lock开始,那我就举几个lock的示例:

代码1

public class Singleton
   2: {
   3:     private static object lockHelper = new object();
   4:     private static Singleton _instance = null;
   5:     public static Singleton Instance
   6:     {
   7:         get
   8:         {
   9:             lock(lockHelper)
  10:             {
  11:                 if(_instance == null)
  12:                     _instance = new Singleton();
  13:             }
  14:             return _instance;
  15:         }
  16:     }
  17: } 
代码2
 public class Singleton
   2: {
   3:     private static Singleton _instance = null;
   4:     public static Singleton Instance
   5:     {
   6:         get
   7:         {
   8:             object lockHelper = new object();
   9:             lock(lockHelper)
  10:             {
  11:                 if(_instance==null)
  12:                     _instance = new Singleton();
  13:             }
  14:             return _instance;
  15:         }
  16:     }
  17: } 

代码3

public class Singleton
   2: {
   3:     private static Singleton _instance = null;
   4:     public static Singleton Instance
   5:     {
   6:         get
   7:         {
   8:             lock(typeof(Singleton))
   9:             {
  10:                 if(_instance==null)
  11:                     _instance = new Singleton();
  12:             }
  13:             return_instance;
  14:         }
  15:     }
  16: } 


代码4

public void DoSomething()
   2: {
   3:     lock(this)
   4:     {
   5:         //dosomething
   6:     }
   7: } 

上面四种代码,对于加锁的方式来说(不讨论其他)哪一种是上上选?对于这个问题的答案留在本文最后解答。

让我们先来看看在Win32的时代,我们如何做到CLR中的lock的效果。在Win32时,Windows为我们提供了一个CRITICAL_SECTION结构,看看上面的单件模式,如果使用CRITICAL_SECTION的方式如何实现?

1: class Singleton
   2: {
   3:     private:
   4:         CRITICAL_SECTIONg_cs;
   5:         static Singleton _instance = NULL;
   6:     public:
   7:         Singleton()
   8:         {
   9:             InitializeCriticalSection(&g_cs);
  10:         }
  11:         static Singleton GetInstance()
  12:         {
  13:             EnterCriticalSection(&g_cs);
  14:             if(_instance!=NULL)
  15:                 _instance=newSingleton();
  16:             LeaveCriticalSection(&g_cs);
  17:             return_instance;
  18:         }
  19:         ~Singleton()
  20:         {
  21:             DeleteCriticalSection(&g_cs);
  22:         }
  23: }

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里定义的:

1: typedef struct _RTL_CRITICAL_SECTION{
   2: PRTL_CRITICAL_SECTION_DEBUGDebugInfo;
   3: //
   4: //Thefollowingthreefieldscontrolenteringandexitingthecritical
   5: //sectionfortheresource
   6: //
   7: LONG LockCount;
   8: LONG RecursionCount;
   9: HANDLE OwningThread;//fromthethread'sClientId->UniqueThread
  10: HANDLE LockSemaphore;
  11: ULONG _PTRSpinCount;//forcesizeon64-bitsystemswhenpacked
  12: }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{ 
   2:     Monitor.Enter(obj); 
   3:     //… 
   4: }finally{ 
   5:     Monitor.Exit(obj); 
   6: } 

(以下内容只限制在本文,为了简单,有的说法很片面,更详细的内容会在后面两篇里描述)

当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
   2: IL_0008:call void [mscorlib]System.Threading.Monitor::Enter(object)
   3: IL_000d:nop
   4: .try
   5: {
   6:     IL_000e:nop
   7:     IL_000f:ldsfld class Singleton Singleton::_instance
   8:     //….
   9:     //…
  10: }
  11: finally
  12: {
  13:     IL_002b:ldloc.1
  14:     IL_002c:call void [mscorlib]System.Threading.Monitor::Exit(object)
  15:     IL_0031:nop
  16:     IL_0032:endfinally
  17: } 

为了简单,我省去了一部分代码。但是很明显,我们看到了System.Threading.Monitor.Enter和Exit。然后我们拿出Reflector看看这个Monitor到底是何方神圣。哎呀,发现Monitor.Enter和Monitor.Exit的代码如下所示:

[MethodImpl(MethodImplOptions.InternalCall)]
   2: public static extern void Enter(objectobj);
   3: [MethodImpl(MethodImplOptions.InternalCall),ReliabilityContract(Consistency.WillNotCorruptState,Cer.Success)]
   4: public static extern void Exit(objectobj); 

只见方法使用了extern关键字,方法上面还标有[MethodImpl(MethodImplOptions.InternalCall)]这样的特性,实际上这说明Enter和Exit的代码是在内部C++的代码实现的。只好拿出Rotor的代码求助了,对于所有"内部实现"的代码,我们可以在sscli20\clr\src\vm\ecall.cpp里找到映射:

FCFuncStart(gMonitorFuncs) 
   2: FCFuncElement("Enter", JIT_MonEnter) 
   3: FCFuncElement("Exit", JIT_MonExit) 
   4: … 
   5: FCFuncEnd() 

原来Enter映射到JIT_MonEnter,一步步的找过去,我们最终到了这里:

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

HCIMPL_MONHELPER(JIT_MonEnterWorker_Portable, Object* obj) 
   2: { 
   3:     //省略大部分代码 
   4:     OBJECTREF objRef = ObjectToOBJECTREF(obj); 
   5:     objRef->EnterObjMonitor(); 
   6: } 
   7: HCIMPLEND 

objRef就是object的引用,EnterObjMonitor方法的代码如下:

   1: void EnterObjMonitor() 
   2: { 
   3:     GetHeader()->EnterObjMonitor(); 
   4: } 

GetHeader()方法获取对象头ObjHeader,在ObjHeader里有对EnterObjMonitor()方法的定义:

   1: void ObjHeader::EnterObjMonitor() 
   2: { 
   3:     GetSyncBlock()->EnterMonitor(); 
   4: } 

 

GetSyncBlock()方法会获取该对象对应的SyncBlock,在SyncBlock里有EnterMonitor方法的定义:

   1: void EnterMonitor() 
   2: { 
   3:     m_Monitor.Enter(); 
   4: } 

 

离核心越来越近了,m_Monitor是一个AwareLock类型的字段,看看AwareLock类内Enter方法的定义:

 1: void AwareLock::Enter() 
   2: { 
   3:     Thread* pCurThread = GetThread(); 
   4:     for (;;) 
   5:     { 
   6:          volatile LONG state = m_MonitorHeld; 
   7:         if (state == 0) 
   8:         { 
   9:             // Common case: lock not held, no waiters. Attempt to acquire lock by 
  10:              // switching lock bit. 
  11:             if (FastInterlockCompareExchange((LONG*)&m_MonitorHeld, 1, 0) == 0) 
  12:             { 
  13:                 break; 
  14:             } 
  15:         } 
  16:         else 
  17:         { 
  18:             // It's possible to get here with waiters but no lock held, but in this 
  19:              // case a signal is about to be fired which will wake up a waiter. So 
  20:              // for fairness sake we should wait too. 
  21:              // Check first for recursive lock attempts on the same thread. 
  22:              if (m_HoldingThread == pCurThread) 
  23:              { 
  24:                  goto Recursion; 
  25:              } 
  26:             // Attempt to increment this count of waiters then goto contention 
  27:             // handling code. 
  28:         if (FastInterlockCompareExchange((LONG*)&m_MonitorHeld, (state + 2), state) == state) 
  29:         { 
  30:              goto MustWait;  
  31:         } 
  32:     } 
  33: } 
  34:     // We get here if we successfully acquired the mutex. 
  35:     m_HoldingThread = pCurThread; 
  36:     m_Recursion = 1; 
  37:     pCurThread->IncLockCount(); 
  38:     return; 
  39: MustWait: 
  40:      // Didn't manage to get the mutex, must wait. 
  41:     EnterEpilog(pCurThread); 
  42:      return; 
  43:     Recursion: 
  44:      // Got the mutex via recursive locking on the same thread. 
  45:     m_Recursion++; 
  46: } 

从上面的代码我们可以看到,先使用GetThread()获取当前的线程,然后取出m_MonitorHeld字段,如果现在没有线程进入临界区,则设置该字段的状态,然后将m_HoldingThread设置为当前线程,从这一点上来这与Win32的过程应该是一样的。如果从m_MonitorHeld字段看,有线程已经进入临界区则分两种情况:第一,是否已进入的线程如当前线程是同一个线程,如果是,则把m_Recursion递加,如果不是,则通过EnterEpilog(pCurThread)方法,当前线程进入线程等待队列。

通过上面的文字描述和代码的跟踪,在我们的大脑中应该有这样一张图了:

 

总结

现在你应该知道lock背后发生的事情了吧。下一次面试的时候,当别人问你同步块索引的时候,你就可以滔滔不绝的和他论述一番。接下来还有两篇分析同步块的其他作用。 
欢迎拍砖,祝编程愉快。




Visual Studio + SOS 小实验

咋一看标题,觉得有些奇怪,同步块索引和HashCode有啥关系呢。从名字上来看离着十万八千里。在不知道细节之前,我也是这样想的,知道细节之后,才发现这两兄弟如此亲密。我们还是先来用Visual Studio + SOS,看一个东西,下面是作为小白兔的示例代码:

 using System;
   2: public class Program
   3: {
   4:     static void Main()
   5:     {
   6:         Foo f = new Foo();
   7:         Console.WriteLine(f.GetHashCode());
   8:  
   9:         Console.ReadLine();
  10:     }
  11: }
  12: //就这么一个简单的类
  13: public class Foo
  14: {
  15:  
  16: }

(使用Visual Studio + SOS调试的时候,请先在项目的属性,调试栏里设置“允许非托管代码调试”)

我们分别在第7行,第9行设置断点,F5运行,当程序停在第一个断点处时(此时f.GetHashCode()还没有执行),我们在Visual Studio的立即窗口里输入:

   1: .load sos.dll
   2: extension C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded
   3: !dso
   4: PDB symbol for mscorwks.dll not loaded
   5: OS Thread Id: 0x1730 (5936)
   6: ESP/REG  Object   Name
   7: 0013ed78 01b72d58 Foo
   8: 0013ed7c 01b72d58 Foo
   9: 0013efc0 01b72d58 Foo
  10: 0013efc4 01b72d58 Foo

使用.load sos.dll加载sos模块,然后使用!dso,我们找到了Foo类型的f对象的内存地址:01b72d58,然后使用Visual Studio调试菜单下的查看内存的窗口,查看f对象头部的内容:

 

阴影遮住的00 00 00 00就是同步块索引所在的地方了,可以看得出来,此时同步块索引的值还是0(后面会对这个做解释),然后继续F5,程序运行到下一个断点处,这个时候f.GetHashCode()也已调用了,细心的你就会发现,原来对象同步块索引所在的地方的值变了:

 

Visual Studio这个内存查看器有个很好的功能,对内存变化的以红色标出。我们看到,原来是00 00 00 00变成了现在的4a 73 78 0f。嗯,看来HashCode的获取和同步块索引还是有一些关系的,不然调用GetHashCode方法为什么同步块索引的值会变化呢。再来看看Console.WriteLine(f.GetHashCode())的输出:

 
不知道着两个值有没有什么关系,我们先把它们都换算成二进制吧。注意,这里的4a 73 78 0f是低位在左,高位在右,下面的十进制是高位再左,低位在右,那4a 73 78 0f实际上就是0x0f78734a了。

0x0f78734a:00001111011110000111001101001010

   58225482:00000011011110000111001101001010

 Rotor源代码

我们先用0补齐32位,突然发现这两者低26位居然是一模一样的(红色标出的部分),这是巧合还是必然?为了一探究竟只好搬出Rotor的源代码,从源代码里看看是否能发现什么东西。还是遵循老路子,我们先从托管代码开始:

   1: public virtual int GetHashCode()
   2: {
   3:    return InternalGetHashCode(this);
   4: }
   5: [MethodImpl(MethodImplOptions.InternalCall)]
   6: internal static extern int InternalGetHashCode(object obj);

在本系列的第一篇文章已经提到过,标记有[MethodImpl(MethodImplOptions.InternalCall)]特性的方法是使用Native Code的方式实现的,在Rotor中,这些代码位于sscli20\clr\src\vm\ecall.cpp文件中:

 FCFuncElement("InternalGetHashCode", ObjectNative::GetHashCode)
   2: FCIMPL1(INT32, ObjectNative::GetHashCode, Object* obj) {
   3:     DWORD idx = 0;
   4:     OBJECTREF objRef(obj);
   5:     idx = GetHashCodeEx(OBJECTREFToObject(objRef));
   6:     return idx;
   7: }
   8: FCIMPLEND
   9: INT32 ObjectNative::GetHashCodeEx(Object *objRef)
  10: {
  11:     // This loop exists because we're inspecting the header dword of the object
  12:     // and it may change under us because of races with other threads.
  13:     // On top of that, it may have the spin lock bit set, in which case we're
  14:     // not supposed to change it.
  15:     // In all of these case, we need to retry the operation.
  16:     DWORD iter = 0;
  17:     while (true)
  18:     {
  19:         DWORD bits = objRef->GetHeader()->GetBits();
  20:  
  21:         if (bits & BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX)
  22:         {
  23:             if (bits & BIT_SBLK_IS_HASHCODE)
  24:             {
  25:                 // Common case: the object already has a hash code
  26:                 return  bits & MASK_HASHCODE;
  27:             }
  28:             else
  29:             {
  30:                 // We have a sync block index. This means if we already have a hash code,
  31:                 // it is in the sync block, otherwise we generate a new one and store it there
  32:                 SyncBlock *psb = objRef->GetSyncBlock();
  33:                 DWORD hashCode = psb->GetHashCode();
  34:                 if (hashCode != 0)
  35:                     return  hashCode;
  36:  
  37:                 hashCode = Object::ComputeHashCode();
  38:  
  39:                 return psb->SetHashCode(hashCode);
  40:             }
  41:         }
  42:         else
  43:         {
  44:             // If a thread is holding the thin lock or an appdomain index is set, we need a syncblock
  45:             if ((bits & (SBLK_MASK_LOCK_THREADID | (SBLK_MASK_APPDOMAININDEX << SBLK_APPDOMAIN_SHIFT))) != 0)
  46:             {
  47:                 objRef->GetSyncBlock();
  48:                 // No need to replicate the above code dealing with sync blocks
  49:                 // here - in the next iteration of the loop, we'll realize
  50:                 // we have a syncblock, and we'll do the right thing.
  51:             }
  52:             else
  53:             {
  54:                 DWORD hashCode = Object::ComputeHashCode();
  55:  
  56:                 DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX | BIT_SBLK_IS_HASHCODE | hashCode;
  57:  
  58:                 if (objRef->GetHeader()->SetBits(newBits, bits) == bits)
  59:                     return hashCode;
  60:                 // Header changed under us - let's restart this whole thing.
  61:             }
  62:         }
  63:     }
  64: }

代码很多,不过大部分操作都是在做与、或、移位等。而操作的对象就是这行代码获取的:objRef->GetHeader()->GetBits(),实际上就是获取同步块索引。

想想,在第一个断点命中的时候,同步块索引的值还是0x00000000,那应该是下面这块代码执行:

   1: DWORD hashCode = Object::ComputeHashCode();
   2: DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX | BIT_SBLK_IS_HASHCODE | hashCode;
   3: if (objRef->GetHeader()->SetBits(newBits, bits) == bits)
   4:     return hashCode;

通过Object的ComputeHashCode方法算出一个哈希值来(由于本文不是关注哈希算法的,所以这里不讨论这个ComputeHashCode方法的实现)。然后进行几个或操作(这里还要与原先的bits或操作是为了保留原来的值,说明这个同步块索引还起了别的作用,比如上篇文章的lock),然后将同步块索引中老的位换掉。从这里我们还看不出来什么。不过,如果我们再次对这个对象调用GetHashCode()方法呢?那同步块索引不再为0x00000000,而是0x0f78734a,在来看看几个定义的常量的值:

   1: #define BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX    0x08000000
   2: #define BIT_SBLK_IS_HASHCODE            0x04000000
   3: #define HASHCODE_BITS                   26
   4: #define MASK_HASHCODE                   ((1<<HASHCODE_BITS)-1)

从刚才设置hashcode的地方可以看到:DWORD newBits = bits | BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX | BIT_SBLK_IS_HASHCODE | hashCode;

所以开头的两个if都可以通过了,返回的hashcode就是bits & MASK_HASHCODE。

这个MASK_HASHCODE是将1向左移26位=100000000000000000000000000,然后减1=00000011111111111111111111111111(低26位全部为1,高6位为0),然后与同步块索引相与,其实这里的作用不就是为了取出同步块索引的低26位的值么。再回想一下本文开头的那个试验,原来不是巧合啊。

连上上一篇,我们可以看到同步块索引不仅仅起到lock的作用,有时还承担着存储HashCode的责任。实际上同步块索引是这样的一个结构:总共32位,高6位作为控制位,后26的具体含义随着高6位的不同而变化,高6位就像很多小开关,有的打开(1),有的关闭(0),不同位的打开和关闭有着不同的意义,程序也就知道低26位到底是干啥的了。这里的设计真是巧妙,不断占用内存很紧凑,程序也可以灵活处理,灵活扩展。

 

后记

本篇和上一篇一样,都是单独将独立的内容拿出来,这样可以更简单的来阐述。比如在本文中,我只设想同步块索引做hashcode的存储,这个时候,同步块索引就干干净净(本文前面的试验中先得到的同步块索引就是一个0),但实际中同步块索引可能担任更多的职责,比如既lock,又要获取HashCode,这个时候情况就更复杂,这个在后面一篇文章会综合各种情况更详细的说明。




前面,我用两篇文章详细的讨论了同步块索引在lock和GetHashCode所起的作用。不过两篇文章是分开来讨论的。那可能有人会问,如果我有一个object,它既作为lock的lockHelper对象,也要调用它的GetHashCode方法该怎么办,难道这个同步块索引还可以承担这两个任务么。同步块索引是可以承担这两个任务,但是里面却隐藏着更大的秘密,我们先来看看与同步块索引相关的结构: 

大致就是这样的一个结构,一个对象的ObjectHeader中的SyncBlockIndex指向一个Sync Block Entry Table中的一项,这里用虚线表示,是说明这里不是使用指针直接的指向,而是一个索引,这样有个什么好处呢,就是CLR可以随便把这个Table放在哪里,也可以按需增大这个Table的容量,反正我这里使用的是索引而不是指针,是间接的指向。这个Table里的每一项都是一个SyncTableEntry,这个SyncTableEntry有两个字段,第一个字段是一个SyncBlock的指针,指向一个SyncBlock对象。还有一个字段是一个Object指针,有了这个指针CLR就可以跟踪这个SyncBlock是哪个对象的,而且SyncTableEntry和SyncBlock不是放在GC管理的内存中,所以可以根据这个Object*来跟踪对应的对象的实例,当对象死亡后,可以回收对应的SyncBlock和SyncTableEntry,不过这个Object的指针是一个弱引用(弱引用的作用是,如果没有任何强引用引用该对象,则该对象可以被认为是垃圾,允许被垃圾收集)。

不过要注意的是,上面这种结构并不是一个对象“与生俱来”的,也就是说对象刚初始化的时候并不如此。当一个对象刚初始化的时候,在ObjectHeader中,SyncBlockIndex字段是为0的,这个在上一篇文章中的Visual Studio + SOS的实验中我们已经见到过。而如果调用对象的GetHashCode方法,则对象的ObjectHeader中的SyncBlockIndex字段的低26位则用来存储该对象的HashCode,而高6位作为一个标识,表示现在SyncBlockIndex作为存储HashCode之用,具体做法就是将这个SyncBlockIndex与BIT_SBLK_IS_HASHCODE (#define BIT_SBLK_IS_HASHCODE 0x04000000)作或运算,判别的时候作一下与运算。这个在上一篇文章中也介绍了。而如果调用对象的GetHashCode方法之后,继续将该对象作为lock的对象使用呢?这个时候SyncBlockIndex的低26位会摇身一变,变成一个索引,而且还与BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX (#define BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX 0x08000000)作一下或运算,表示这个SyncBlockIndex现在啊既有存储HashCode之功用,又要作为lock的对象。

那既然这低26位变成了索引,那原来的HashCode跑到哪里去了呢?这个就要一探SyncBlock的结构了:

 

我们看到最后一个字段,这个字段就是如果SyncBlockIndex还做其他用途是,CLR会将计算所得的hashcode放到这里。而如果对象只作lock对象使用,而没有调用GetHashCode方法,则这个字段为0。根据调用的顺序,这个m_dwHashCode的设置有两种方式:

1、已经调用了GetHashCode方法,然后作lock之用,那这里的m_dwHashCode就是之前存储在SyncBlockIndex中的低26位。

2、先作lock之用,然后调用GetHashCode,那m_dwHashCode就是当时新生成的HashCode,然后放在这里的。

从图中我们还有ADIndex这么一个字段,这个字段是表示当前这个对象属于哪个AppDomain,实际上这个字段也可以在SyncBlockIndex里设置,但是如果SyncBlockIndex要担负别的责任,比如该对象作为lock对象时,ADIndex就在SyncBlock里这个字段设置了。关于为什么需要这个ADIndex我现在还没弄清楚,等我弄明白了,再来更新这篇文章。

SyncBlock的第一个字段是AwareLock,实际上这个东西和我第一篇文章中提到的CRITICAL_SECTION结构是一样的,具体细节可以参见“揭示同步索引块(上)-从lock开始”这篇文章。

而这里的SLink字段有两个作用:

1、当SyncBlock是活动的时候,这个字段将作为一个队列,保存在这里排队的线程(作为lock对象时)。

2、当SyncBlock被回收时,这个字段就作为空闲的SyncBlock列表。

 

好了,同步块索引的相关用途和结构在、下这三篇文章中基本讨论完了。没想到这么一个小小的,不起眼的同步块索引却有这么一番作用。从这个同步块索引的使用上,也可以看得出来微软的CLR Team在设计的时候,对内存、性能可谓斤斤计较,充分的利用每一个bit,一个bit的不同就会表示不同的作用。






评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值