原文网址:http://blog.chinaunix.net/uid-23769728-id-3173282.html

这篇博文很长,虽然这是下篇,但还没结束,benchmark方面的东西正在进行中,另外还有一些问题我自己也在和别人讨论...所以我想除了还有“结束语”篇(其实这篇我基本写完了,但是还没最终盖棺论定,有些问题尚需要进一步讨论)之外,还应该会有个“实际性能测试”篇...理想是美好的,但是现实时间总是不够用滴。因此,我想说,如果这篇博文最后烂尾了,请网友们--把我埋在,埋在春天里。。。
======================================================================

mutex_lock的slow path的调用链为:
mutex_lock --> __mutex_lock_slowpath --> __mutex_lock_common,所有的性能优化的代码又都集中在__mutex_lock_common中,这个函数有点长,等下我们不妨肢解来慢慢看。。。

mutex_lock在slow path当中优化的基本原理是:拥有mutex lock的进程总是会在尽可能短的时间里释放。基于此,mutex_lock的slow path部分会尽量避免进入睡眠状态,它试图通过短暂的spin来等待拥有互斥锁的进程释放它。__mutex_lock_common的主体结构是两个 for循环,中间加入对能否再次获得锁的判断逻辑。

/*
* Lock a mutex (possibly interruptible), slowpath:
*/
static inline int __sched
__mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
                    struct lockdep_map *nest_lock, unsigned long ip)
{
        struct task_struct *task = current;
首先,我们能够达到这里,表明当前进程在一次争夺互斥锁的战争中失败了,此时几方争夺的互斥锁mutex中的owner即为成功获得该锁的task_struct对象... 
先关闭内核可抢占性,是因为在后续的处理中,我们不希望被别的进程抢占出处理器,因为对当前进程而言,1st priority的事情是获得锁。高优先级进程在此时出现也不用抢占当前进程,因为当前进程接下来要么睡眠(那么就无需被抢占了),要么获得锁而再次打开 可抢占性。
        preempt_disable();
内核配置选项,目前是内核默认的配置
        #ifdef CONFIG_MUTEX_SPIN_ON_OWNER        
源码中下面是一段很重要的注释,核心要点是mutex优化所基于的现实基础:一个获得互斥锁的进程极大的可能会在很短的时间内释放掉它。所以不同于 semaphore的实现,mutex在第一次没获得锁的情形下,如果发现拥有该锁的进程正在别的处理器上运行且锁上没有其他等待者(也即只有当前进程在 等待该锁),那么当前进程试图spin(说白了就是忙等待),这样有极大的概率是可以免去两次进程切换的开销,而重新获得之前竞争但未能成功的互斥锁 ----性能提升处。理论上,为了获得锁而进行的spin,其时间长短不应该超过两次进程切换的时间开销,否则此处优化将没有意义。

下面是第一个for循环, 循环中有两个break,一个直接return 0
       for (;;) {
                struct task_struct *owner;

/*
                 * If there's an owner, wait for it to either
                 * release the lock or go to sleep.
                 */
                owner = ACCESS_ONCE(lock->owner);
                if (owner && !mutex_spin_on_owner(lock, owner))
                        break;

if (atomic_cmpxchg(&lock->count, 1, 0) == 1) {
                        lock_acquired(&lock->dep_map, ip);
                        mutex_set_owner(lock);
                        preempt_enable();
                        return 0;
                }

/*
                 * When there's no owner, we might have preempted between the
                 * owner acquiring the lock and setting the owner field. If
                 * we're an RT task that will live-lock because we won't let
                 * the owner complete.
                 */
                if (!owner && (need_resched() || rt_task(task)))
                        break;

/*
                 * The cpu_relax() call is a compiler barrier which forces
                 * everything in this loop to be re-loaded. We don't need
                 * memory barriers as we'll eventually observe the right
                 * values at the cost of a few extra spins.
                 */
                arch_mutex_cpu_relax();
        } //the first for loop
先看第一个break,if条件里owner基本上都会满足,如果owner=NULL则说明当前拥有锁的进程可能已经释放了锁,所以可以立刻退出该循 环。if条件中的mutex_spin_on_owner()是个非常有意思的函数,它通过per-jiffies的方式来确保可以在极短的时间里 break那个while循环。这段代码设计是如此地富有想象力,它通过if (need_resched())使得函数能在jiffies级别上跳出while循环,但是代码优化的性能提升则体现在owner_running中, 因为拥有锁的进程在极短的时间(肯定是低于jiffies这个级别的,可能在us级甚至更低)释放锁,如果通过if (need_resched())退出循环,则基本说明了本次优化的失败,事实上还导致了性能的倒退(因为即便在HZ=1000的系统中,jiffies的级别也是非常粗糙的,现代处理器的进程切换的开销可能只在几个us或者几十个us,如果让一个进程为了获得mutex lock而去spin几个jiffies,那么这简直就是暴敛天物了,如果这个时间让当前进程睡眠,那么其他进程就可以获得CPU资源,而1个jiffies可以抵得上几十上百个进程切换的时间开销,根本就不需要在乎两次进程切换的时间开销。但是IBM的Paul同学认为,如果让一个进程在获得mutex lock的情形下运行几个jiffies再释放lock,那么这可能是个bug。我不认为这是对的,mutex lock不同于spin lock,不应该对mutex_lock与mutex_unlock之间的代码执行时间做什么限定)。代码在mutex_spin_on_owner()中通过 while循环来密切关注拥有锁的进程运行情况,一旦从while中跳出来,说明当前进程已经释放锁(通过owner_running),或者当前拥有锁 的进程运行的时间够长(可能为几个jiffies),最后返回前检查lock->owner,如果是NULL,源码注释中也讲得很清 楚,"which is a sign for heavy contention",在当前进程还没来得及下手前,lock已经被他人横刀夺爱了,此种情形下最好去sleep了,否则spin的时间就足以抵得上一 次进程切换的代价。。。

中间的return 0是个非常理想的情况,当前进程spin的过程中,锁的拥有者已经释放了锁,这个最简单,二次获得锁成功而直接返回。

接下来的break是当前进程在对方先行抢占到了锁但是还没来得及设定owner的时候抢占了它,或者当前进程是个实时进程,此时需要进入后半段处理。

在第二个for循环之前,从代码明显看到设计者已经在为当前进程进入sleep状态做最后的准备(如果代码进入到第二个for循环,实际上意味着本次优化 的失败,从性能的角度,这条路径上的性能肯定没有semaphore来得高,至少是没什么优势,因为你前面毕竟spin了一下,最后才sleep,但是 semaphore根本就不spin,第一次没拿到锁的话直接就sleep了),不过它在进入第二个for循环之前还是要做了个atomic_xchg动 作,主要是对第一个for循环中的两个break进行处理,看看是否足够幸运能再次获得锁。

第二个for循环的代码已经和semaphore的slow path实现基本一样了,所以我们看到对mutex的优化集中在第一个for循环之中,而且有很大的概率在那里会重新获得锁。

我们看到对mutex的优化其实遵循了代码优化的一般原则,即集中优化整个代码执行中出现的hot-spot(引申到高概率spot)。因为在实际使用当中,大多数情况 下,mutex_lock与mutex_unlock之间的代码都比较简短,使得获得锁的进程可以很快释放锁(因此,从性能优化的角度,这个也可以作为使 用mutex的一条一般原则)。如果系统中大部分拥有互斥锁的进程在mutex_lock与unlock之间执行时间比较长,那么相对于使用 semaphore,我相信使用mutex会使得系统性能降低:因为很大的概率,mutex都经过一段spin(虽然这段时间极短)之后最终还是进入 sleep,而semaphore则直接进入sleep,没有了spin的过程。

【转】深层次探讨mutex与semaphore之间的区别(下)的更多相关文章

  1. mutex与semaphore的区别

    网摘1:Mutex 的发音是 /mjuteks/ ,其含义为互斥(体),这个词是Mutual Exclude的缩写.Mutex在计算机中是互斥也就是排他持有的一种方式,和信号量-Semaphore有可 ...

  2. 线程同步 –Mutex和Semaphore

    上一篇介绍了同步事件EventWaitHandle,以及它的两个子类型AutoResetEvent和ManualResetEvent.下面接着介绍WaitHandle的另外两个子类型Mutex和Sem ...

  3. Mutex vs Semaphore

    What are the differences between Mutex vs Semaphore? When to use mutex and when to use semaphore? Co ...

  4. 内核必看: spinlock、 mutex 以及 semaphore

    linux 内核的几种锁介绍 http://wenku.baidu.com/link?url=RdvuOpN3RPiC5aY0fKi2Xqw2MyTnpZwZbE07JriN7raJ_L6Ss8Ru1 ...

  5. Mutex vs Semaphore vs Monitor vs SemaphoreSlim

    C#开发者(面试者)都会遇到Mutex,Semaphore,Monitor,SemaphoreSlim这四个与锁相关的C#类型,本文期望以最简洁明了的方式阐述四种对象的区别. 线程安全 教条式理解 如 ...

  6. 你真的会玩SQL吗?EXISTS和IN之间的区别

    你真的会玩SQL吗?系列目录 你真的会玩SQL吗?之逻辑查询处理阶段 你真的会玩SQL吗?和平大使 内连接.外连接 你真的会玩SQL吗?三范式.数据完整性 你真的会玩SQL吗?查询指定节点及其所有父节 ...

  7. 深入理解 sudo 与 su 之间的区别【转】

    深入理解 sudo 与 su 之间的区别 两个命令的最大区别是: sudo 命令需要输入当前用户的密码,su 命令需要输入 root 用户的密码.另外一个区别是其默认行为.sudo 命令只允许使用提升 ...

  8. 深入理解 sudo 与 su 之间的区别

    深入理解 sudo 与 su 之间的区别 作者: Himanshu Arora 译者: LCTT zhb127 在早前的一篇文章中,我们深入讨论了 sudo 命令的相关内容.同时,在该文章的末尾有提到 ...

  9. select、poll、epoll之间的区别总结

    select.poll.epoll之间的区别总结 05/05. 2014 select,poll,epoll都是IO多路复用的机制.I/O多路复用就通过一种机制,可以监视多个描述符,一旦某个描述符就绪 ...

随机推荐

  1. js实现键盘操作对div的移动或改变-------Day43

    <爸爸去哪儿>的第二季据说要开播了额,有点小期待,不知道这一季的小宝贝们会有多萌,还会甜到心底吧, 哈哈,还记得那个风一样的女子呢,不知道她如今怎样了. 言归正传,继续今天的记录,实际上在 ...

  2. [转] C++中临时对象及返回值优化

    http://www.cnblogs.com/xkfz007/articles/2506022.html 什么是临时对象? C++真正的临时对象是不可见的匿名对象,不会出现在你的源码中,但是程序在运行 ...

  3. C#操作INI配置文件示例

    源文件地址:http://pan.baidu.com/share/link?shareid=2536126078&uk=1761850335创建如图所示的控件: 源代码: using Syst ...

  4. Android深入浅出之 AudioTrack分析

    Android深入浅出之Audio 第一部分 AudioTrack分析 一 目的 本文的目的是通过从Audio系统来分析Android的代码,包括Android自定义的那套机制和一些常见类的使用,比如 ...

  5. ASP.NET-FineUI开发实践-16(二)

    实现那还差点,在事件参数里我传了一个boolall选中状态参数,这个参数由前台给的,RowSelect 传的是index 行号,就是改这,通过$符号来分开的, if (commandArgs.Leng ...

  6. Word 查找替换,通配符一览表

    Word查找替换详细用法及通配符一览表 使用通配符要查找“?”或者“*”,可输入“\?”和“\*”,\1\2\3依次匹配数对括号内容查找(a)12(b)   替换\2XY\1   结果:bXYa ([ ...

  7. HTTPS双向认证

    生成证书 openssl genrsa -des3 -out server.key 2048 openssl req -new -x509 -key server.key -out ca.crt -d ...

  8. 关于timestamp的二三事

    之所以要写timestamp的随笔,是因为之前对它的理解存在误区,so. I have to remind myself by writing this informal essay. 微软文档链接: ...

  9. jQuery ajax - serialize() 方法

    http://www.jb51.net/article/60849.htm http://www.w3school.com.cn/jquery/ajax_serialize.asp

  10. 配置Statspack

    配置Statspack 配置前需要了解3个内容. 1.创建Statspack模式使用的密码. 2.Statspack使用的默认表空间. 3.Statspack使用的临时表空间. Create Tabl ...