我写了一个小程序来比较Windows中Critical Section vs Mutex的性能。
在我跑的测试中,获得关键部分似乎更慢:O任何人都可以解释为什么这两件事花费的时间几乎相同,以及内部发生的事情。
这是我使用的计时器 - http://cplus.about.com/od/howtodothingsi2/a/timing.htm
#include "stdafx.h"
#include<iostream>
#include<vector>
#include "h_timer.h"
#include<WinBase.h>
#include<Windows.h>
#include<stdio.h>
#define MAX_THREADS 2000
//Comment and Uncomment this to enable/disable critialSection / Mutex
#define CRIT 1
using namespace std;
HANDLE Mutex;
CRITICAL_SECTION critSection;
DWORD WINAPI Contention( LPVOID );
int main( void )
{
HANDLE Thread[MAX_THREADS];
DWORD ThreadID;
int i;
#ifdef CRIT
//create a critical section
InitializeCriticalSection(&critSection);
#else
// Create a mutex with no initial owner
Mutex = CreateMutex( NULL, FALSE,NULL);
#endif
// Create worker threads
CStopWatch timer, tempTimer;
timer.startTimer();
for( i=0; i < MAX_THREADS; i++ )
{
Thread[i] = CreateThread( NULL,
0,(LPTHREAD_START_ROUTINE)Contention,NULL,0,&ThreadID);
}
WaitForMultipleObjects(MAX_THREADS, Thread, TRUE, INFINITE);
timer.stopTimer();
cout<<endl<<"Elapsed Time:"<<timer.getElapsedTime();
cin.get();
// Close thread and mutex handles
for( i=0; i < MAX_THREADS; i++ )
CloseHandle(Thread[i]);
CloseHandle(Mutex);
return 0;
}
DWORD WINAPI Contention( LPVOID lpParam )
{
#ifdef CRIT
EnterCriticalSection(&critSection);
//printf("ThreadId: %d\n",GetCurrentThreadId());
//printf("Let's try Again. %d\n\n", GetCurrentThreadId());
LeaveCriticalSection(&critSection);
#else
// lpParam not used in this example
UNREFERENCED_PARAMETER(lpParam);
DWORD dwCount=0, dwWaitResult;
// Request ownership of mutex.
dwWaitResult = WaitForSingleObject(
ghMutex, // handle to mutex
INFINITE); // no time-out interval
dwCount++;
ReleaseMutex(ghMutex);
#endif
return TRUE;
}
对于2000线程,在四核HPZ210上,两者都需要大约1.5秒。
答案 0 :(得分:13)
我认为有两个因素:
主要是 - 您的程序由线程创建开销主导。您正在创建和销毁2000个线程,并且每个线程仅访问一次互斥锁/ CS。创建线程所花费的时间淹没了锁定/解锁时间的差异。
此外 - 您可能没有测试这些锁被优化的用例。尝试生成两个线程,每个线程试图访问互斥锁/ CS数千次。
答案 1 :(得分:9)
关键部分是用户模式和内核模式的混合体。他们尝试通过使用自旋锁(用户模式)来保持线程不受上下文切换的影响,然后再回到更昂贵的信号量(内核模式)。这可以提高实际场景中的性能。相反,互斥体纯粹是内核模式,会立即等待,执行上下文切换。
通过在2000个线程之间进行100%争用,你已经做到了这一点,所以关键部分几乎肯定会尽可能地旋转,占用CPU,然后最终完成互斥锁所做的事情并在内核模式下执行等待。因此,在这种情况下,他们变慢是有道理的。
日本人说的是什么。线程创建非常慢。