4
原子OPS我正在做一些測試用一個簡單的程序測量上使用atomic_add_64 Vs的互斥鎖方法一個64位的值的簡單原子增量的性能。 什麼我百思不得其解的是atomic_add是2Pthread互斥VS Solaris中
編輯的因素不是互斥鎖慢！我已經做了更多的測試。看起來像原子比互斥更快，可擴展到8個併發線程。之後，原子的性能顯着降低。
我測試的平臺是：
的SunOS 5.10 Generic_141444-09 sun4u的SPARC SUNW，太陽火V490
CC：孫C++ 5.9 SunOS_sparc補丁124863-03 2008/03/12
程序很簡單：
#include <stdio.h>
#include <stdint.h>
#include <pthread.h>
#include <atomic.h>
uint64_t g_Loops = 1000000;
volatile uint64_t g_Counter = 0;
volatile uint32_t g_Threads = 20;
pthread_mutex_t g_Mutex;
pthread_mutex_t g_CondMutex;
pthread_cond_t g_Condition;
void LockMutex()
{
pthread_mutex_lock(&g_Mutex);
}
void UnlockMutex()
{
pthread_mutex_unlock(&g_Mutex);
}
void InitCond()
{
pthread_mutex_init(&g_CondMutex, 0);
pthread_cond_init(&g_Condition, 0);
}
void SignalThreadEnded()
{
pthread_mutex_lock(&g_CondMutex);
--g_Threads;
pthread_cond_signal(&g_Condition);
pthread_mutex_unlock(&g_CondMutex);
}
void* ThreadFuncMutex(void* arg)
{
uint64_t counter = g_Loops;
while(counter--)
{
LockMutex();
++g_Counter;
UnlockMutex();
}
SignalThreadEnded();
return 0;
}
void* ThreadFuncAtomic(void* arg)
{
uint64_t counter = g_Loops;
while(counter--)
{
atomic_add_64(&g_Counter, 1);
}
SignalThreadEnded();
return 0;
}
int main(int argc, char** argv)
{
pthread_mutex_init(&g_Mutex, 0);
InitCond();
bool bMutexRun = true;
if(argc > 1)
{
bMutexRun = false;
printf("Atomic run!\n");
}
else
printf("Mutex run!\n");
// start threads
uint32_t threads = g_Threads;
while(threads--)
{
pthread_t thr;
if(bMutexRun)
pthread_create(&thr, 0,ThreadFuncMutex, 0);
else
pthread_create(&thr, 0,ThreadFuncAtomic, 0);
}
pthread_mutex_lock(&g_CondMutex);
while(g_Threads)
{
pthread_cond_wait(&g_Condition, &g_CondMutex);
printf("Threads to go %d\n", g_Threads);
}
printf("DONE! g_Counter=%ld\n", (long)g_Counter);
}
我們盒試運行的結果是：
$ CC -o atomictest atomictest.C
$ time ./atomictest
Mutex run!
Threads to go 19
...
Threads to go 0
DONE! g_Counter=20000000
real 0m15.684s
user 0m52.748s
sys 0m0.396s
$ time ./atomictest 1
Atomic run!
Threads to go 19
...
Threads to go 0
DONE! g_Counter=20000000
real 0m24.442s
user 3m14.496s
sys 0m0.068s
你碰到這種類型在Solaris性能差異？任何想法爲什麼發生這種情況
在Linux相同的代碼（用gcc __sync_fetch_and_add）產生在所述互斥verstion 5倍的性能提升。
感謝， Octav
這實在不應該來作爲所有巨大的驚喜。 「無鎖」不一定意味着「更快」。 – 2012-04-16 15:40:38
我同意這一點，儘管通常認爲原子操作比互斥鎖更高效，至少對於像這樣的簡單情況，即Windows上的InterlockedIncrement比CriticalSection +增量快，Linux上的_sync_fetch_and_add比pthreads_mutex_lock快得多+增量。爲什麼我們會在Solaris上使用原子操作，如果它們比Mutex-es慢兩倍？用原子能產生更好的性能的用例是什麼？ – 2012-04-16 15:49:55
請在發佈前正確地縮進您的代碼。 – 2012-04-16 15:54:19