临界区总是更快吗? [英] Is Critical Section always faster?

查看:100
本文介绍了临界区总是更快吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在调试一个多线程应用程序,发现内部结构为 CRITICAL_SECTION 。我发现CRITICAL_SECTION的数据成员 LockSemaphore 很有趣。

I was debugging a multi-threaded application and found the internal structure of CRITICAL_SECTION. I found data member LockSemaphore of CRITICAL_SECTION an interesting one.

看起来 LockSemaphore 是一个自动重置事件(顾名思义,不是信号量)和操作系统线程在第一次等待被其他线程锁定的 Critcal Section 时,以静默方式创建此事件。

It looks like LockSemaphore is an auto-reset event (not a semaphore as the name suggests) and operating system creates this event silently when first time a thread waits on Critcal Section which is locked by some other thread.

现在,我想知道临界区总是更快吗?事件是一个内核对象,每个关键部分对象都与事件对象相关联,那么关键部分如何比Mutex等其他内核对象更快?另外,内部事件对象实际上如何影响Critical部分的性能?

Now, I am wondering is Critical Section always faster? Event is a kernel object and each Critical section object is associated with event object then how Critical Section can be faster compared to other kernel objects like Mutex? Also, how does internal event object actually affects the performance of Critical section ?

这是 CRITICAL_SECTION 的结构:

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


推荐答案

当他们说关键部分是快速时,它们的意思是在尚未被另一个线程锁定的情况下获取一个便宜。

When they say that a critical section is "fast", they mean "it's cheap to acquire one when it isn't already locked by another thread".

[请注意,如果已经 ]

[Note that if it is already locked by another thread, then it doesn't matter nearly so much how fast it is.]

之所以如此之快,是因为在进入内核之前,它已经快了。在 LONG 字段之一上使用等效于 InterlockedIncrement 的字段(也许在 LockCount 字段),如果成功,那么它将认为获得的锁没有进入内核。

The reason why it's fast is because, before going into the kernel, it uses the equivalent of InterlockedIncrement on one of those LONG field (perhaps on the the LockCount field) and if it succeeds then it considers the lock aquired without having gone into the kernel.

InterlockedIncrement API是在用户模式下作为 LOCK INC操作码实现的,换句话说,您无需进行任何环形过渡即可获得无争议的关键部分。

The InterlockedIncrement API is I think implemented in user mode as a "LOCK INC" opcode ... in other words you can acquire an uncontested critical section without doing any ring transition into the kernel at all.

这篇关于临界区总是更快吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆