InitializeCriticalSectionAndSpinCount

2015/08/03

The InitializeCriticalSectionAndSpinCount function initializes a critical section object and sets the spin count for the critical section.

BOOL InitializeCriticalSectionAndSpinCount(
LPCRITICAL_SECTION lpCriticalSection,
// pointer to critical section
DWORD dwSpinCount // spin count for critical section
);SetCriticalSectionSpinCountThe SetCriticalSectionSpinCount function sets the spin count for the specified critical section. DWORD SetCriticalSectionSpinCount(
LPCRITICAL_SECTION lpCriticalSection,
// pointer to critical section
DWORD dwSpinCount // spin count for critical section
);

当线程试图进入另一个线程拥有的关键代码段时，调用线程就立即被置于等待状态。这意
味着该线程必须从用户方式转入内核方式（大约1 0 0 0个C P U周期）。这种转换是要付出很大代价的。

因此， InitializeCriticalSectionAndSpinCount 的作用不同于InitializeCriticalSection 之处就在于设置了一个循环锁，不至于使线程立刻被置于等待状态而耗费大量的CPU周期，而在dwSpinCount后才转为内核方式进入等待状态。通常dwSpinCount设为4000较为合适。

实际上对 CRITICAL_SECTION 的操作非常轻量，为什么还要加上旋转锁的动作呢？其实这个函数在单cpu的电脑上是不起作用的，只有当电脑上存在不止一个cpu，或者一个cpu但多核的时候，才管用。

如果临界区用来保护的操作耗时非常短暂，比如就是保护一个reference counter，或者某一个flag，那么几个时钟周期以后就会离开临界区。可是当这个thread还没有离开临界区之前，另外一个thread试图进入此临界区——这种情况只会发生在多核或者smp的系统上——发现无法进入，于是这个thread会进入睡眠，然后会发生一次上下文切换。我们知道context switch是一个比较耗时的操作，据说需要数千个时钟周期，那么其实我们只要再等多几个时钟周期就能够进入临界区，现在却多了数千个时钟周期的开销，真是是可忍孰不可忍。

所以就引入了InitializeCriticalSectionAndSpinCount函数，它的第一个参数是指向cs的指针，第二个参数是旋转的次数。我的理解就是一个循环次数，比如说N，那么就是说此时EnterCriticalSection()函数会内部循环判断此临界区是否可以进入，直到可以进入或者N次满。我们增加的开销是最多N次循环，我们可能获得的红利是数千个时钟周期。对于临界区内很短的操作来讲，这样做的好处是大大的。

MSDN上说，他们对于堆管理器使用了N=4000的旋转锁，然后“This gives great performance and scalability in almost all worst-case scenarios.” 可见还是很有用的

Copyright：http://blog.csdn.net/niitlcj/article/details/4996992

Blogroll