注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

gmd20的个人空间

// 编程和生活

 
 
 

日志

 
 

spinlock 的很多线程抢占时的性能优化,补充 pthread mutex 和 futex相关知识  

2012-03-12 23:06:46|  分类: 程序设计 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

      微博里面看到有人说spinlock线程比较多在以前抢占锁时性能比价差。因为之前搜索过c++了spinlock,大多解决办法就是 那种指数的规避的办法咯,就是如果实在不行,就先让cpu指数的等待时间空转几次,实在还是拿不到锁在休眠。可以去看nginx的 core 代码的spinlock文件的实现。像那些boost的spinlock也差不多大,之前说过了。 这样很多个线程都在抢那个锁的时候,不至于都在那里忙等,比较好一点。

      在网上搜索一下 “spinlock Exponential Backoff”  应该就可以找到相关资料了。

      不过 “spinlock Exponential Backoff”  也还是不够好,呵呵,所以有人又搞了 queue lock。 就是大家不要抢咯,一个个排队来拿锁了。应该是这样吧?  就是少了争抢的。我最讨厌那种饭堂吃饭不排队的人了,大家都在那里抢,谁都吃不到,呵呵spinlock 的很多线程抢占时的性能优化 - widebright - widebright的个人空间

       去网上搜索应该可以找到资料吧。“Anderson Queue Lock” “CLH Queue Lock”  还是什么的。

下面这篇文章里面都有提到上面那些知识的,可以先去看一下下面这个。

Spin Locks and Contention  By Guy Kalinski

http://www.cs.tau.ac.il/~afek/Spin%20Locks%20and%20Contention.ppt


2012-03-27 补充 The Art of Multiprocessor Programming.pdf 一书的第7章 “Spin Locks and Co7ntention” 也说倒了“Exponential Backoff” 和“Queue Locks”。后面 的“Chapter Notes”还提到了其他很多的改进,MCSLock,CLHLock HBOLock HCLHLock(Hierarchical Locks)等等改进spinlock性能的尝试。可以去看一下。

 这书还是写的分厂不错的,推荐一下,后面的免锁设计数据结构和硬件原理的附录也不错。

=================================================================

大家很喜欢那spinlock和  mutex 来比较,我个人也是比较喜欢spinlock一点,可能linux内核代码看多了,总是觉得spinlock性能要好。不过这应该分场合,如果按照下面这个。

 

比如这篇 Pthreads并行编程之spin lock与mutex性能对比分析

http://www.parallellabs.com/2010/01/31/pthreads-programming-spin-lock-vs-mutex-performance-analysis/

--------------------------

Fast Userspace Mutexes   

     用户使用futex的时候,大多的锁操作都是在用户操作里面进行的,不用进入内核,所以性能很好吧。然后有碰到大家都在竞争这个锁的时候,才通过futex系统调用进入内核,内核就会把竞争者做个排队,放到队列里面去。然后唤醒的时候,从队列里面依次唤醒。

      看来 “排队”是解决“拥挤”(锁竞争)的好办法啊。spinlock 的很多线程抢占时的性能优化,补充 pthread mutex 和 futex相关知识 - widebright - widebright的个人空间

     根据futex的实现,如果锁竞争不激烈,大多的操作都是在用户级完成的(也是那些原子汇编指令吧),这个跟spinlock应该没有太多的区别,两者性能不会相差的太大。 两者的区别是futex碰到竞争马上会进入内核去排队,而spinlock会忙等一会在那里重试,然后指数级的等待时间都不到,到了一个固定的timeout之后才主动的让内核有切换的机会。这两种办法有各自的优点吧,很难说哪个更好一些。不过两种不同的办法,初略看来是会导致一点不同的区别,futex那种进入内核线程“排队”的做法应该是可以保证各个线程的公平性的,spinlock这种嘛应该是不能保证线程的公平性的,如果有一个线程一直在那里循环很快的拿锁然后释放可能大多时间都会被他抢去了,其他的线程可能很难抢到锁,导致“饥饿”状态。

 

-------------------------

http://lxr.linux.no/linux/Documentation/robust-futexes.txt

这篇文章主要将使用futex的进程意外退出的时候,怎么快速恢复锁的状态,不能拿锁,然后又挂了,别人也没法用了。 不过开始的对futex的介绍还是写的挺好的。

 

  11A futex is in essence a user-space address, e.g. a 32-bit lock variable

  12field. If userspace notices contention (the lock is already owned and

  13someone else wants to grab it too) then the lock is marked with a value

  14that says "there's a waiter pending", and the sys_futex(FUTEX_WAIT)

  15syscall is used to wait for the other guy to release it. The kernel

  16creates a 'futex queue' internally, so that it can later on match up the

  17waiter with the waker - without them having to know about each other.

  18When the owner thread releases the futex, it notices (via the variable

  19value) that there were waiter(s) pending, and does the

  20sys_futex(FUTEX_WAKE) syscall to wake them up.  Once all waiters have

  21taken and released the lock, the futex is again back to 'uncontended'

  22state, and there's no in-kernel state associated with it. The kernel

  23completely forgets that there ever was a futex at that address. This

  24method makes futexes very lightweight and scalable.

 

---------------------------

SYSCALL_DEFINE6(futex

        return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);

 

------------------------

2628long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,

2629                u32 __user *uaddr2, u32 val2, u32 val3)

 

2643        switch (cmd) {

2644        case FUTEX_WAIT:

2645                val3 = FUTEX_BITSET_MATCH_ANY;

2646        case FUTEX_WAIT_BITSET:

2647                ret = futex_wait(uaddr, flags, val, timeout, val3);   ///等待 

2648                break;

2649        case FUTEX_WAKE:

2650                val3 = FUTEX_BITSET_MATCH_ANY;

2651        case FUTEX_WAKE_BITSET:

2652                ret = futex_wake(uaddr, flags, val, val3);      //唤醒 

 

-------------------------------

static int futex_wait(u32 __user *uaddr, unsigned int flags, u32 val,

      ret = futex_wait_setup(uaddr, val, flags, &q, &hb);

1902        /* queue_me and wait for wakeup, timeout, or a signal. */

1903        futex_wait_queue_me(hb, &q, to);         ////一直等在这里等待唤醒了,应该

         if (!unqueue_me(&q))

 

         if (!signal_pending(current))       //被信号意外唤醒的,跳到开头再次重试

        

----------------------------------

 

1752/**

1753 * futex_wait_queue_me() - queue_me() and wait for wakeup, timeout, or signal

1754 * @hb:         the futex hash bucket, must be locked by the caller

1755 * @q:          the futex_q to queue up on

1756 * @timeout:    the prepared hrtimer_sleeper, or null for no timeout

1757 */

1758static void futex_wait_queue_me(struct futex_hash_bucket *hb, struct futex_q *q,

1759                                struct hrtimer_sleeper *timeout)

1760{

1761        /*

1762         * The task state is guaranteed to be set before another task can

1763         * wake it. set_current_state() is implemented using set_mb() and

1764         * queue_me() calls spin_unlock() upon completion, both serializing

1765         * access to the hash list and forcing another memory barrier.

1766         */

1767        set_current_state(TASK_INTERRUPTIBLE);

1768        queue_me(q, hb);

 

-------------------------

1478/**

1479 * queue_me() - Enqueue the futex_q on the futex_hash_bucket

1480 * @q:  The futex_q to enqueue

1481 * @hb: The destination hash bucket

1482 *

1483 * The hb->lock must be held by the caller, and is released here. A call to

1484 * queue_me() is typically paired with exactly one call to unqueue_me().  The

1485 * exceptions involve the PI related operations, which may use unqueue_me_pi()

1486 * or nothing if the unqueue is done as part of the wake process and the unqueue

1487 * state is implicit in the state of woken task (see futex_wait_requeue_pi() for

1488 * an example).

1489 */

1490static inline void queue_me(struct futex_q *q, struct futex_hash_bucket *hb)

1491        __releases(&hb->lock)

1492{

1493        int prio;

1494

1495        /*

1496         * The priority used to register this element is

1497         * - either the real thread-priority for the real-time threads

1498         * (i.e. threads with a priority lower than MAX_RT_PRIO)

1499         * - or MAX_RT_PRIO for non-RT threads.

1500         * Thus, all RT-threads are woken first in priority order, and

1501         * the others are woken last, in FIFO order.

1502         */

1503        prio = min(current->normal_prio, MAX_RT_PRIO);

1504

1505        plist_node_init(&q->list, prio);

1506        plist_add(&q->list, &hb->chain);   ///加到等待队列里面去,plist是一个优先级队列,

1507        q->task = current;

1508        spin_unlock(&hb->lock);

1509}

 

----------------------------------------

 

  评论这张
 
阅读(1591)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017