关键部分总是更快吗？

Question

我正在调试一个多线程应用程序,并找到了内部结构CRITICAL_SECTION.我发现LockSemaphoreCRITICAL_SECTION的数据成员很有趣.

它看起来像是LockSemaphore一个自动重置事件(顾名思义不是信号量),并且当第一次线程等待Critcal Section某个其他线程锁定时,操作系统会静默创建此事件.

现在,我想知道关键部分总是更快吗？Event是一个内核对象,每个Critical部分对象都与事件对象相关联,那么Critical Section与其他内核对象(如Mutex)相比,如何更快？此外,内部事件对象如何实际影响Critical部分的性能？

这是结构CRITICAL_SECTION:

struct RTL_CRITICAL_SECTION
{
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;
};

Answer 1

当他们说一个关键部分是"快"时,他们的意思是"当它还没有被另一个线程锁定时获得一个便宜".

[注意,如果是已经被另一个线程锁定的话,不要紧,几乎与其说它是多么快.]

它之所以快,是因为在进入内核之前,它使用了InterlockedIncrement其中一个LONG字段(可能是在LockCount字段上)的等价物,如果成功,那么它会认为锁是在没有进入内核的情况下获得的.

该InterlockedIncrementAPI是我在用户模式认为实现为"LOCK INC"的操作码......换句话说,你可以获取无争议的关键部分没有做任何环过渡到内核在所有.

Answer 2

在性能工作中,很少有东西属于"总是"类别:)如果你自己实现的东西与使用其他原语的操作系统关键部分类似,那么在大多数情况下,这种情况会更慢.

回答问题的最佳方法是进行性能测量.OS对象的执行方式非常依赖于场景.例如,如果争用率较低,则关键部分通常被视为"快速".如果锁定时间小于旋转计数时间,则它们也被认为是快速的.

最重要的是要确定关键部分的争用是否是应用程序中的第一个限制因素.如果没有,那么只需简单地使用一个关键部分,并处理您的应用程序主要瓶颈(或颈部).

如果关键部分性能至关重要,那么您可以考虑以下因素.

1. 仔细设置"热门"关键部分的旋转锁定计数.如果表现至关重要,那么这里的工作是值得的.请记住,虽然自旋锁确实避免了用户模式到内核转换,但它会以极快的速度消耗CPU时间 - 在旋转时,没有其他任何东西可以使用该CPU时间.如果锁定保持的时间足够长,则旋转线程将实际阻塞,从而释放该CPU以执行其他工作.
2. 如果您有读写器模式,那么请考虑使用Slim Reader/Writer(SRW)锁.这方面的缺点是它们仅适用于Vista和Windows Server 2008及更高版本的产品.
3. 您可以将条件变量与临界区一起使用,以最大限度地减少轮询和争用,仅在需要时唤醒线程.同样,Vista和Windows Server 2008及更高版本的产品也支持这些产品.
4. 考虑使用互锁单链接列表(SLIST) - 这些是高效且"无锁定"的.更好的是,XP和Windows Server 2003及更高版本的产品支持它们.
5. 检查您的代码 - 您可以通过重构某些代码并使用互锁操作或SLIST进行同步和通信来分解"热"锁.

总而言之 - 具有锁争用的调优方案可能具有挑战性(但有趣!)工作.专注于测量应用程序性能并了解热路径的位置.在该xperf工具Windows性能工具箱在这里你的朋友:)我们刚刚发布了4.5版本,在Microsoft Windows SDK的Windows 7和.NET Framework 3.5 SP1(ISO在这里,网络安装在这里).你可以在这里找到xperf工具的论坛.V4.5完全支持Win7,Vista,Windows Server 2008 - 所有版本.