Vincent — Tue, 21 Sep 2010 07:15:00 GMT

POSIX threads(��U�Pthreads)是在多核�q�_��上进行�ƈ行编�E�的一套常用的API。线�E�同�?Thread Synchronization)是�ƈ行编�E�中非常重要的通讯手段�Q�其中最典型的应用就是用Pthreads提供的锁机制(lock)来对多个�U�程之间�?享的临界�?Critical Section)�q�行保护(另一�U�常用的同步机制是barrier)�?br>
Pthreads提供了多�U�锁机制�Q?br>(1) Mutex�Q�互斥量�Q�：pthread_mutex_***
(2) Spin lock�Q�自旋锁�Q�：pthread_spin_***
(3) Condition Variable�Q�条件变量）�Q�pthread_con_***
(4) Read/Write lock�Q�读写锁�Q�：pthread_rwlock_***

Pthreads提供的Mutex锁操作相关的API主要有：
pthread_mutex_lock (pthread_mutex_t *mutex);
pthread_mutex_trylock (pthread_mutex_t *mutex);
pthread_mutex_unlock (pthread_mutex_t *mutex);

Pthreads提供的与Spin Lock锁操作相关的API主要有：
pthread_spin_lock (pthread_spinlock_t *lock);
pthread_spin_trylock (pthread_spinlock_t *lock);
pthread_spin_unlock (pthread_spinlock_t *lock);

从实现原理上来讲�Q�Mutex属于sleep-waiting�c�d��的锁。例如在一个双核的机器上有两个�U�程(�U�程A和线�E�B)�Q�它们分别运行在Core0和Core1上。假讄��E�A惌��通过pthread_mutex_lock操作��d��C��个��界区的锁�Q�而此时这个锁正被�U�程B所持有�Q�那么线�E�A��׃��被阻�?blocking)�Q�Core0 会在此时�q�行上下文切�?Context Switch)��线�E�A�|�于�{�待队列中，此时Core0��可以运行其他的��d��(例如另一个线�E�C)而不必进行忙�{�待。而Spin lock则不�Ӟ��它属于busy-waiting�c�d��的锁�Q�如果线�E�A是��用pthread_spin_lock操作去请求锁�Q�那么线�E�A��׃��一直在 Core0上进行忙�{�待�q�不停的�q�行锁请求，直到得到�q�个锁�ؓ止�?br>
如果大家��L��阅Linux glibc中对pthreads API的实现NPTL(Native POSIX Thread Library) 的源码的�?使用”getconf GNU_LIBPTHREAD_VERSION”命��o可以得到我们�pȝ��中NPTL的版本号)�Q�就会发现pthread_mutex_lock()操作如果没有锁成功的话就会调用system_wait()的系�l�调用�ƈ��当前线�E�加入该mutex的等待队列里。而spin lock则可以理解�ؓ在一个while(1)循环中用内嵌的汇�~�代码实现的锁操�?印象中看�q�一��论文介�l�说在linux内核中spin lock操作只需要两条CPU指��o�Q�解锁操作只用一条指令就可以完成)。有兴趣的朋友可以参考另一个名为sanos的微内核中pthreds API的实玎ͼ�mutex.c spinlock.c�Q�尽��与NPTL中的代码实现不尽相同�Q�但是因为它的实现非常简单易懂，�Ҏ��们理解spin lock和mutex的特性还是很有帮助的�?br>
那么在实际编�E�中mutex和spin lcok哪个的性能更好呢？我们知道spin lock在Linux内核中有非常�q�泛的利用，那么�q�是不是说明spin lock的性能更好呢？下面让我们来用实际的代码��试一下（��L��保你的系�l�中已经安装了最�q�的g++�Q��?br>
查看源代码打印帮�?01 // Name: spinlockvsmutex1.cc

002 // Source: [url]http://www.alexonlinux.com/pthread-mutex-vs-pthread-spinlock[/url]

003 // Compiler(spin lock version): g++ -o spin_version -DUSE_SPINLOCK spinlockvsmutex1.cc -lpthread

004 // Compiler(mutex version): g++ -o mutex_version spinlockvsmutex1.cc -lpthread

005 #include

006 #include

007 #include

008 #include

009 #include

010 #include

011 #include

012

013 #define LOOPS 50000000

014

015 using namespace std;

016

017 list the_list;

018

019 #ifdef USE_SPINLOCK

020 pthread_spinlock_t spinlock;

021 #else

022 pthread_mutex_t mutex;

023 #endif

024

025 //Get the thread id

026 pid_t gettid() { return syscall( __NR_gettid ); }

027

028 void *consumer(void *ptr)

029 {

030    int i;

031

032    printf("Consumer TID %lun", (unsigned long)gettid());

033

034    while (1)

035    {

036 #ifdef USE_SPINLOCK

037       pthread_spin_lock(&spinlock);

038 #else

039       pthread_mutex_lock(&mutex);

040 #endif

041

042       if (the_list.empty())

043       {

044 #ifdef USE_SPINLOCK

045          pthread_spin_unlock(&spinlock);

046 #else

047          pthread_mutex_unlock(&mutex);

048 #endif

049          break;

050       }

051

052       i = the_list.front();

053       the_list.pop_front();

054

055 #ifdef USE_SPINLOCK

056       pthread_spin_unlock(&spinlock);

057 #else

058       pthread_mutex_unlock(&mutex);

059 #endif

060    }

061

062    return NULL;

063 }

064

065 int main()

066 {

067    int i;

068    pthread_t thr1, thr2;

069    struct timeval tv1, tv2;

070

071 #ifdef USE_SPINLOCK

072    pthread_spin_init(&spinlock, 0);

073 #else

074    pthread_mutex_init(&mutex, NULL);

075 #endif

076

077    // Creating the list content...

078    for (i = 0; i < LOOPS; i++)

079       the_list.push_back(i);

080

081    // Measuring time before starting the threads...

082    gettimeofday(&tv1, NULL);

083

084    pthread_create(&thr1, NULL, consumer, NULL);

085    pthread_create(&thr2, NULL, consumer, NULL);

086

087    pthread_join(thr1, NULL);

088    pthread_join(thr2, NULL);

089

090    // Measuring time after threads finished...

091    gettimeofday(&tv2, NULL);

092

093    if (tv1.tv_usec > tv2.tv_usec)

094    {

095       tv2.tv_sec--;

096       tv2.tv_usec += 1000000;

097    }

098

099    printf("Result - %ld.%ldn", tv2.tv_sec - tv1.tv_sec,

100       tv2.tv_usec - tv1.tv_usec);

101

102 #ifdef USE_SPINLOCK

103    pthread_spin_destroy(&spinlock);

104 #else

105    pthread_mutex_destroy(&mutex);

106 #endif

107

108    return 0;

109 }

该程序运行过�E�如下：�ȝ��E�先初始化一个list�l�构�Q��ƈ�Ҏ��LOOPS的值将对应数量的entry插入该list�Q�之后创��Z��个新�U�程�Q�它们都执行consumer()�q�个��d��。两个被创徏的新�U�程同时对这个list�q�行pop操作。主�U�程会计��从创徏两个新线�E�到两个新线�E�结束之间所用的旉��Q�输��Zؓ下文中的”Result “�?br>
��试机器参数�Q?br>Ubuntu 9.04 X86_64
Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
4.0 GB Memory

从下面是��试�l�果�Q?br>
查看源代码打印帮�?1 pxcwan@pxcwan-desktop:~/Workspace/mutex$ g++ -o spin_version -DUSE_SPINLOCK spinvsmutex1.cc -lpthread

02 pxcwan@pxcwan-desktop:~/Workspace/mutex$ g++ -o mutex_version spinvsmutex1.cc -lpthread

03 pxcwan@pxcwan-desktop:~/Workspace/mutex$ time ./spin_version

04 Consumer TID 5520

05 Consumer TID 5521

06 Result - 5.888750

07

08 real 0m10.918s

09 user 0m15.601s

10 sys 0m0.804s

11

12 pxcwan@pxcwan-desktop:~/Workspace/mutex$ time ./mutex_version

13 Consumer TID 5691

14 Consumer TID 5692

15 Result - 9.116376

16

17 real 0m14.031s

18 user 0m12.245s

19 sys 0m4.368s

可以看见spin lock的版本在该程序中表现出来的性能更好。另外值得注意的是sys旉��Q�mutex版本��p��了更多的�pȝ��调用旉��Q�这��是因�ؓmutex会在锁冲�H�时调用system wait造成的�?br>
但是�Q�是不是说spin lock��׃��定更好了呢？让我们再来看一个锁冲突�E�度非常剧烈的实例程序：

查看源代码打印帮�?1 //Name: svm2.c

02 //Source: [url]http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Locks[/url]

03 //Compile(spin lock version): gcc -o spin -DUSE_SPINLOCK svm2.c -lpthread

04 //Compile(mutex version): gcc -o mutex svm2.c -lpthread

05 #include

06 #include

07 #include

08 #include

09

10 #define       THREAD_NUM    2

11

12 pthread_t g_thread[THREAD_NUM];

13 #ifdef USE_SPINLOCK

14 pthread_spinlock_t g_spin;

15 #else

16 pthread_mutex_t g_mutex;

17 #endif

18 __uint64_t g_count;

19

20 pid_t gettid()

21 {

22    return syscall(SYS_gettid);

23 }

24

25 void *run_amuck(void *arg)

26 {

27       int i, j;

28

29       printf("Thread %lu started.n", (unsigned long)gettid());

30

31       for (i = 0; i < 10000; i++) {

32 #ifdef USE_SPINLOCK

33          pthread_spin_lock(&g_spin);

34 #else

35             pthread_mutex_lock(&g_mutex);

36 #endif

37             for (j = 0; j < 100000; j++) {

38                      if (g_count++ == 123456789)

39                               printf("Thread %lu wins!n", (unsigned long)gettid());

40             }

41 #ifdef USE_SPINLOCK

42          pthread_spin_unlock(&g_spin);

43 #else

44             pthread_mutex_unlock(&g_mutex);

45 #endif

46       }

47

48       printf("Thread %lu finished!n", (unsigned long)gettid());

49

50       return (NULL);

51 }

52

53 int main(int argc, char *argv[])

54 {

55       int i, threads = THREAD_NUM;

56

57       printf("Creating %d threads...n", threads);

58 #ifdef USE_SPINLOCK

59       pthread_spin_init(&g_spin, 0);

60 #else

61       pthread_mutex_init(&g_mutex, NULL);

62 #endif

63       for (i = 0; i < threads; i++)

64             pthread_create(&g_thread[i], NULL, run_amuck, (void *) i);

65

66       for (i = 0; i < threads; i++)

67             pthread_join(g_thread[i], NULL);

68

69       printf("Done.n");

70

71       return (0);

72 }

�q�个�E�序的特征就是��界区非常大，�q�样两个�U�程的锁竞争会非常的剧烈。当然这个是一个极端情况，实际应用�E�序中��界区不会如此大，锁竞争也不会如此�Ȁ烈。测试结果显�C�mutex版本性能更好�Q?br>
查看源代码打印帮�?1 pxcwan@pxcwan-desktop:~/Workspace/mutex$ time ./spin

02 Creating 2 threads...

03 Thread 31796 started.

04 Thread 31797 started.

05 Thread 31797 wins!

06 Thread 31797 finished!

07 Thread 31796 finished!

08 Done.

09

10 real 0m5.748s

11 user 0m10.257s

12 sys 0m0.004s

13

14 pxcwan@pxcwan-desktop:~/Workspace/mutex$ time ./mutex

15 Creating 2 threads...

16 Thread 31801 started.

17 Thread 31802 started.

18 Thread 31802 wins!

19 Thread 31802 finished!

20 Thread 31801 finished!

21 Done.

22

23 real 0m4.823s

24 user 0m4.772s

25 sys 0m0.032s

另外一个值得注意的细节是spin lock耗费了更多的user time。这��是因�ؓ两个�U�程分别�q�行在两个核上，大部分时间只有一个线�E�能拿到锁，所以另一个线�E�就一直在它运行的core上进行忙�{�待�Q�CPU占用率一直是100%�Q�而mutex则不同，当对锁的��h��p�|后上下文切换��׃��发生�Q�这样就能空��Z��个核来进行别的运��Q务了。（其实�q�种上下文切换对已经拿着锁的那个�U�程性能也是有媄响的�Q�因为当该线�E�释放该锁时它需要通知操作�pȝ��d��醒那些被��d��的线�E�，�q�也是额外的开销�Q?br>
�ȝ��
�Q?�Q�Mutex适合寚w��操作非常频繁的场景，�q�且��h��更好的适应性。尽��相比spin lock它会��p��更多的开销�Q�主要是上下文切换）�Q�但是它能适合实际开发中复杂的应用场景，在保证一定性能的前提下提供更大的灵�z�d��?br>
�Q?�Q�spin lock的lock/unlock性能更好(��p��更少的cpu指��o)�Q�但是它只适应用于临界��行时间很短的场景。而在实际软�g开发中�Q�除非程序员对自��q��E�序的锁操作行�ؓ非常的了解，否则使用spin lock不是一个好��L��(通常一个多�U�程�E�序中对锁的操作有数以万�ơ，如果��p�|的锁操作(contended lock requests)�q�多的话��׃��费很多的时间进行空�{�待)�?br>
�Q?�Q�更保险的方法或许是先（保守的）使用 Mutex�Q�然后如果对性能�q�有�q�一步的需求，可以��试使用spin lock�q�行调优。毕竟我们的�E�序不像Linux kernel那样�Ҏ��能需求那么高(Linux Kernel最常用的锁操作是spin lock和rw lock)�?br>
2010�q?�?日补讎ͼ��q�个观点在Oracle的文档中得到了支持：

During configuration, Berkeley DB selects a mutex implementation for the architecture. Berkeley DB normally prefers blocking-mutex implementations over non-blocking ones. For example, Berkeley DB will select POSIX pthread mutex interfaces rather than assembly-code test-and-set spin mutexes because pthread mutexes are usually more efficient and less likely to waste CPU cycles spinning without getting any work accomplished.

p.s.调用syscall(SYS_gettid)和syscall( __NR_gettid )都可以得到当前线�E�的id:)

转蝲��h��明来�? [url]www.parallellabs.com[/url]
------------------------------------------------------------------------------

spinlock与linux内核调度的关�p?br>

　　作者：刘洪涛，华清�q�见嵌入式培训中心高�U�讲师，ARM公司授权ATC讲师�?br>
�q�告插播信息
�l�库最新热卖芯片：

　　关于自旋锁用法介�l�的文章�Q�已�l�有很多�Q�但有些�l�节的地方点的还不够透。我�q�里��把我个��为大家容易有疑问的地�Ҏ��出来讨论一下�?br>
　　一、自旋锁�Q�spinlock�Q�简�?br>
　　自旋锁在同一时刻只能被最多一个内�怓Q务持有，所以一个时��d��有一个线�E�允许存在于临界��Z��。这点可以应用在多处理机器、或�q�行在单处理器上的抢占式内核中需要的锁定服务�?br>
　　二、信号量��?br>
　　�q�里也介�l�下信号量的概念�Q�因为它的用法和自旋锁有�怼�的地斏V�?br>
　　Linux中的信号量是一�U�睡眠锁。如果有一个�Q务试图获得一个已被持有的信号量时�Q�信号量会将其推入等待队列，然后让其睡眠。这时处理器获得自由��L��行其它代码。当持有信号量的�q�程��信号量释放后，在等待队列中的一个�Q务将被唤醒，从而便可以获得�q�个信号量�?br>
　　三、自旋锁和信号量�Ҏ��

　　在很多地方自旋锁和信号量可以选择��M��一个��用，但也有一些地方只能选择某一�U�。下面对比一些两者的用法�?br>
　　�?-1自旋锁和信号量对�?br>

　　四、自旋锁与linux内核�q�程调度关系

　　我们讨论下表1-1中的�W?�U�情况（其它几种情况比较好理解）�Q�如果��界区可能包含引�v睡眠的代码则不能使用自旋锁，否则可能引�v死锁�?br>
　　那么��Z��么信号量保护的代码可以睡眠而自旋锁��׃��能呢�Q?br>
　　先看下自旋锁的实现方法吧�Q�自旋锁的基本�Ş式如下：

　　spin_lock(&mr_lock);

　　//临界�?br>
　　spin_unlock(&mr_lock);

　　跟踪一下spin_lock(&mr_lock)的实�?br>
　　#define spin_lock(lock) _spin_lock(lock)

　　#define _spin_lock(lock) __LOCK(lock)

　　#define __LOCK(lock) \

　　do { preempt_disable(); __acquire(lock); (void)(lock); } while (0)

　　注意�?#8220;preempt_disable()”�Q�这个调用的功能�?#8220;��x��?#8221;�Q�在spin_unlock中会重新开启抢占功能）。从中可以看出，使用自旋锁保护的区域是工作在非抢占的状态；即��获取不到锁，�?#8220;自旋”状态也是禁止抢占的。了解到�q�，我想�׃��应该能够理解��Z��自旋锁保护的代码不能睡眠了。试想一下，如果在自旋锁保护的代码中间睡眠，此时发生�q�程调度�Q�则可能另外一个进�E�会再次调用spinlock保护的这�D�代码。而我们现在知道了即��在获取不到锁�?#8220;自旋”状态，也是��止抢占的，�?#8220;自旋”又是动态的�Q�不会再睡眠了，也就是说在这个处理器上不会再有进�E�调度发生了�Q�那么死锁自然就发生了�?br>
　　�׃��可以�ȝ��下自旋锁的特点：

　　�?单处理器非抢占内�怸��Q�自旋锁会在�~�译时被忽略�Q?br>
　　�?单处理器抢占内核下：自旋锁仅仅当作一个设�|�内核抢占的开养I��

　　�?多处理器下：此时才能完全发挥��旋锁的作用，自旋锁在内核中主要用来防止多处理器中�q�发讉K��临界区，防止内核抢占造成的竞争�?br>
　　五、linux抢占发生的时�?br>
　　最后在了解下linux抢占发生的时��_��抢占分�ؓ用户抢占和内核抢占�?br>
　　用户抢占在以下情况下产生�Q?br>
　　�?从系�l�调用返回用��L��?br>
　　�?从中断处理程序返回用��L��?br>
　　内核抢占会发生在�Q?br>
　　�?当从中断处理�E�序�q�回内核�I�间的时候，且当时内核具有可抢占性；

　　�?当内�总�码再一�ơ具有可抢占性的时候。（�?spin_unlock�Ӟ��

　　�?如果内核中的��d��昑ּ�的调用schedule()

　　�?如果内核中的��d��d��?br>
　　基本的进�E�调度就是发生在旉��中断后，�q�且发现�q�程的时间片已经使用完了�Q�则发生�q�程抢占。通常我们会利用中断处理程序返回内核空间的时候可以进行内核抢占这个特性来提高一些I/O操作的实时性，如：当I/O事�g发生的是时候，对应的中断处理程序被�Ȁ�z�，当它发现有进�E�在�{�待�q�个I/O事�g的时候，它会�Ȁ�zȝ��待进�E�，�q�且讄��当前正在执行�q�程的need_resched标志�Q�这样在中断处理�E�序�q�回的时候，调度�E�序被激�z�，原来在等待I/O事�g的进�E�（很可能）获得执行权，从而保证了对I/O事�g的相对快速响应（毫秒�U�）。可以看出，在I/O事�g发生的时候，I/O事�g的处理进�E�会抢占当前�q�程�Q�系�l�的响应速度与调度时间片的长度无兟�?br>

Vincent 2010-09-21 15:15 发表评论

国产精品对白刺激久久久,久久精品国产清自在天天线,伊人久久亚洲综合影院