 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
Linux互斥锁、条件变量和信号量
下载积分：5
内容提示：Linux互斥锁、条件变量和信号量
文档格式：DOC|
浏览次数：295|
上传日期： 17:25:50|
文档星级：
全文阅读已结束，如果下载本文需要使用
 5 积分
下载此文档
该用户还上传了这些文档
Linux互斥锁、条件变量和信号量
关注微信公众号君，已阅读到文档的结尾了呢~~
Linux互斥锁、条件变量和信号量
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
Linux互斥锁、条件变量和信号量
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口以下试题来自：
问答题简答题Linux系统中线程的同步方式有互斥量、信号量和条件变量等。假设现在需要设计一个多线程的应用程序，试分析一下以上几种同步方式分别可在什么场合下使用。
Mutex互斥量，用于操作某个临界资源时对该资源上锁，以实现互斥地对独占资源的使用Semophore信号灯，信号灯内有一计数......
为您推荐的考试题库
您可能感兴趣的试卷
你可能感兴趣的试题
1.问答题 （1）指令执行引起的异常软件中断、未定义指令（包括所要求的协处理器不存在是的协处理器指令）、预取址中止（存储器故障）、......2.问答题 在Linux中启动一个进程有手工启动和调度启动两种方式：（1）手工启动用户在输入端发出命令，直接启动一个进程的......3.问答题 两种实现方法，一种是继承Thread，另外一种是实现接口Runnable。同步的实现方法有两种，分别是synchronized，wait与notify。......4.问答题 Boot Loader相当于普通pc机的BIOS，是在系统复位后执行的第一段代码。因此，整个系统的加载启动任务就完全由Boot Loader来完......5.问答题
进程查看的命令是ps和top。
进程调度的命令有at，crontab，batch，kill。请输入关键词：
　　在编程中，引入了对象互斥锁的概念，来保证共享数据操作的完整性。每个对象都对应于一个可称为& 互斥锁& 的标记，这个标记用来保证在任一时刻，只能有一个线程访问该对象。下面举例：
　　在Posix Thread中定义有一套专门用于线程同步的mutex函数。
　　1． 创建和销毁
　　有两种方法创建互斥锁，静态方式和动态方式。POSIX定义了一个宏PTHREAD_MUTEX_INITIALIZER来静态初始化互斥锁，方法如下： pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER; 在LinuxThreads实现中，pthread_mutex_t是一个结构，而PTHREAD_MUTEX_INITIALIZER则是一个结构常量。
　　动态方式是采用pthread_mutex_init()函数来初始化互斥锁，API定义如下： int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr) 其中mutexattr用于指定互斥锁属性（见下），如果为NULL则使用缺省属性。
　　pthread_mutex_destroy ()用于注销一个互斥锁，API定义如下： int pthread_mutex_destroy(pthread_mutex_t *mutex) 销毁一个互斥锁即意味着释放它所占用的资源，且要求锁当前处于开放状态。由于在Linux中，互斥锁并不占用任何资源，因此LinuxThreads中的 pthread_mutex_destroy()除了检查锁状态以外（锁定状态则返回EBUSY）没有其他动作。
　　2． 互斥锁属性
　　互斥锁的属性在创建锁的时候指定，在LinuxThreads实现中仅有一个锁类型属性，不同的锁类型在试图对一个已经被锁定的互斥锁加锁时表现不同。当前（glibc2.2.3,linuxthreads0.9）有四个值可供选择：
　　* PTHREAD_MUTEX_TIMED_NP，这是缺省值，也就是普通锁。当一个线程加锁以后，其余请求锁的线程将形成一个等待队列，并在解锁后按优先级获得锁。这种锁策略保证了资源分配的公平性。
　　* PTHREAD_MUTEX_RECURSIVE_NP，嵌套锁，允许同一个线程对同一个锁成功获得多次，并通过多次unlock解锁。如果是不同线程请求，则在加锁线程解锁时重新竞争。
　　* PTHREAD_MUTEX_ERRORCHECK_NP，检错锁，如果同一个线程请求同一个锁，则返回EDEADLK，否则与PTHREAD_MUTEX_TIMED_NP类型动作相同。这样就保证当不允许多次加锁时不会出现最简单情况下的死锁。
　　* PTHREAD_MUTEX_ADAPTIVE_NP，适应锁，动作最简单的锁类型，仅等待解锁后重新竞争。
　　3． 锁操作
　　锁操作主要包括加锁pthread_mutex_lock()、解锁pthread_mutex_unlock()和测试加锁 pthread_mutex_trylock()三个，不论哪种类型的锁，都不可能被两个不同的线程同时得到，而必须等待解锁。对于普通锁和适应锁类型，解锁者可以是同进程内任何线程；而检错锁则必须由加锁者解锁才有效，否则返回EPERM；对于嵌套锁，文档和实现要求必须由加锁者解锁，但实验结果表明并没有这种限制，这个不同目前还没有得到解释。在同一进程中的线程，如果加锁后没有解锁，则任何其他线程都无法再获得锁。
　　& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
　　& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
　　int pthread_mutex_lock(pthread_mutex_t *mutex)
　　int pthread_mutex_unlock(pthread_mutex_t *mutex)
　　int pthread_mutex_trylock(pthread_mutex_t *mutex)
　　& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
　　& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &
　　pthread_mutex_trylock()语义与pthread_mutex_lock()类似，不同的是在锁已经被占据时返回EBUSY而不是挂起等待。
　　4． 其他
　　POSIX 线程锁机制的Linux实现都不是取消点，因此，延迟取消类型的线程不会因收到取消信号而离开加锁等待。值得注意的是，如果线程在加锁后解锁前被取消，锁将永远保持锁定状态，因此如果在关键区段内有取消点存在，或者设置了异步取消类型，则必须在退出回调函数中解锁。
　　这个锁机制同时也不是异步信号安全的，也就是说，不应该在信号处理过程中使用互斥锁，否则容易造成死锁。　　
本词条对我有帮助0
积木知识库中的词条内容仅供参考，如果您需要解决实际问题，建议您咨询相关领域专业人士
如果您认为本词条还需进一步完善，欢迎您也来参与编辑词条&&&&让我们共同来完善IT领域的百科全书
浏览该词条的网友还浏览了
最新收录词条
热门脚本语言：博客访问： 988892
博文数量： 167
博客积分： 2234
博客等级： 大尉
技术积分： 3214
注册时间：
未来很长。
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
可递归锁与非递归锁转载自《线程同步之利器(1)——可递归锁与非递归锁》最常见的进程/线程的同步方法有互斥锁（或称互斥量Mutex)，读写锁(rdlock)，条件变量(cond)，信号量(Semophore)等。在Windows系统中，临界区（Critical&Section）和事件对象(Event)也是常用的同步方法。&&简单的说，互斥锁保护了一个临界区，在这个临界区中，一次最多只能进入一个线程。如果有多个进程在同一个临界区内活动，就有可能产生竞态条件(race&condition)导致错误。&&读写锁从广义的逻辑上讲，也可以认为是一种共享版的互斥锁。如果对一个临界区大部分是读操作而只有少量的写操作，读写锁在一定程度上能够降低线程互斥产生的代价。&&条件变量允许线程以一种无竞争的方式等待某个条件的发生。当该条件没有发生时，线程会一直处于休眠状态。当被其它线程通知条件已经发生时，线程才会被唤醒从而继续向下执行。条件变量是比较底层的同步原语，直接使用的情况不多，往往用于实现高层之间的线程同步。使用条件变量的一个经典的例子就是线程池(Thread&Pool)了。&&在学习操作系统的进程同步原理时，讲的最多的就是信号量了。通过精心设计信号量的PV操作，可以实现很复杂的进程同步情况（例如经典的哲学家就餐问题和理发店问题）。而现实的程序设计中，却极少有人使用信号量。能用信号量解决的问题似乎总能用其它更清晰更简洁的设计手段去代替信号量。&&本系列文章的目的并不是为了讲解这些同步方法应该如何使用（AUPE的书已经足够清楚了）。更多的是讲解很容易被人忽略的一些关于锁的概念，以及比较经典的使用与设计方法。文章会涉及到递归锁与非递归锁（recursive&mutex和non-recursive&mutex），&区域锁(Scoped&Lock)，策略锁(Strategized&Locking)，读写锁与条件变量，双重检测锁(DCL)，锁无关的数据结构(Locking&free)，&自旋锁等等内容，希望能够抛砖引玉。那么我们就先从递归锁与非递归锁说开去吧:)1&可递归锁与非递归锁1.1&概念&&&&在所有的线程同步方法中，恐怕互斥锁(mutex)的出场率远远高于其它方法。互斥锁的理解和基本使用方法都很容易，这里不做更多介绍了。&&&&Mutex可以分为递归锁(recursive&mutex)和非递归锁(non-recursive&mutex)。可递归锁也可称为可重入锁(reentrant&mutex)，非递归锁又叫不可重入锁(non-reentrant&mutex)。&&二者唯一的区别是，同一个线程可以多次获取同一个递归锁，不会产生死锁。而如果一个线程多次获取同一个非递归锁，则会产生死锁。&&Windows下的Mutex和Critical&Section是可递归的。Linux下的pthread_mutex_t锁默认是非递归的。可以显示的设置PTHREAD_MUTEX_RECURSIVE属性，将pthread_mutex_t设为递归锁。在大部分介绍如何使用互斥量的文章和书中，这两个概念常常被忽略或者轻描淡写，造成很多人压根就不知道这个概念。但是如果将这两种锁误用，很可能会造成程序的死锁。请看下面的程序。&&&&MutexLock&&&&&&&&&&&void&foo()&&&&&&{&&&&&&&&&&mutex.lock();&&&&&&&&&&//&do&something&&&&&&&&&&mutex.unlock();&&&&&&}&&&&&&&&&void&bar()&&&&&&&&{&&&&&&&&&mutex.lock();&&&&&&&&&//&do&something&&&&&&&&&foo();&&&&&&&&&mutex.unlock();&&&&&&&&&&}&&&&&foo函数和bar函数都获取了同一个锁，而bar函数又会调用foo函数。如果MutexLock锁是个非递归锁，则这个程序会立即死锁。因此在为一段程序加锁时要格外小心，否则很容易因为这种调用关系而造成死锁。&&&&不要存在侥幸心理，觉得这种情况是很少出现的。当代码复杂到一定程度，被多个人维护，调用关系错综复杂时，程序中很容易犯这样的错误。庆幸的是，这种原因造成的死锁很容易被排除。&&&&但是这并不意味着应该用递归锁去代替非递归锁。递归锁用起来固然简单，但往往会隐藏某些代码问题。比如调用函数和被调用函数以为自己拿到了锁，都在修改同一个对象，这时就很容易出现问题。因此在能使用非递归锁的情况下，应该尽量使用非递归锁，因为死锁相对来说，更容易通过调试发现。程序设计如果有问题，应该暴露的越早越好。1.2&如何避免&&&&&&&为了避免上述情况造成的死锁，AUPE&v2一书在第12章提出了一种设计方法。即如果一个函数既有可能在已加锁的情况下使用，也有可能在未加锁的情况下使用，往往将这个函数拆成两个版本---加锁版本和不加锁版本(添加nolock后缀)。&&&例如将foo()函数拆成两个函数。&&&&//&不加锁版本&&&&&&void&foo_nolock()&&&&&&{&&&&&&&&&&//&do&something&&&&&&}&&&&&&//&加锁版本&&&&&&void&fun()&&&&&&{&&&&&&&&&&mutex.lock();&&&&&&&&&foo_nolock();&&&&&&&&&mutex.unlock();&&&&&}&&&&&为了接口的将来的扩展性，可以将bar()函数用同样方法拆成bar_withou_lock()函数和bar()函数。&&&在Douglas&C.&Schmidt（ACE框架的主要编写者）的“Strategized&Locking,&Thread-safe&Interface,&and&Scoped&Locking”论文中，&&&提出了一个基于C
的线程安全接口模式(Thread-safe&interface&pattern)，与AUPE的方法有异曲同工之妙。&&&即在设计接口的时候，每个函数也被拆成两个函数，没有使用锁的函数是private或者protected类型，&&&使用锁的的函数是public类型。接口如下：&&&&class&T&&&&&&{&&&&&&public:&&&&&&&&&&foo();&//加锁&&&&&&&&&&bar();&//加锁&&&&&&private:&&&&&&&&&&foo_nolock();&&&&&&&&&&bar_nolock();&&&&&&}&&作为对外接口的public函数只能调用无锁的私有变量函数，而不能互相调用。在函数具体实现上，这两种方法基本是一样的。&&&上面讲的两种方法在通常情况下是没问题的，可以有效的避免死锁。但是有些复杂的回调情况下，则必须使用递归锁。比如foo函数调用了外部库的函数，而外部库的函数又回调了bar()函数，此时必须使用递归锁，否则仍然会死锁。AUPE&一书在第十二章就举了一个必须使用递归锁的程序例子。1.3&读写锁的递归性&&&&读写锁（例如Linux中的pthread_rwlock_t）提供了一个比互斥锁更高级别的并发访问。读写锁的实现往往是比互斥锁要复杂的，因此开销通常也大于互斥锁。在我的Linux机器上实验发现，单纯的写锁的时间开销差不多是互斥锁十倍左右。&&&&在系统不支持读写锁时，有时需要自己来实现，通常是用条件变量加读写计数器实现的。有时可以根据实际情况，实现读者优先或者写者优先的读写锁。&&&读写锁的优势往往展现在读操作很频繁，而写操作较少的情况下。如果写操作的次数多于读操作，并且写操作的时间都很短，则程序很大部分的开销都花在了读写锁上，这时反而用互斥锁效率会更高些。&&&相信很多同学学习了读写锁的基本使用方法后，都写过下面这样的程序（Linux下实现）。程序1&&&&#include&&pthread.h&&&&&&&int&main()&&&&&&{&&&&&&&&&&pthread_rwlock_t&&&&&&&&&&&pthread_rwlock_rdlock(&rwl);&&&&&&&&&&pthread_rwlock_wrlock(&rwl);&&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&&return&-1;&&&&&&}&&&&程序2&&#include&&pthread.h&&&&&int&main()&&&&{&&&&&&&&&pthread_rwlock_t&&&&&&&&&&pthread_rwlock_wrlock(&rwl);&&&&&&&&&pthread_rwlock_rdlock(&rwl);&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&return&-1;&&&&}&&&&你会很疑惑的发现，程序1先加读锁，后加写锁，按理来说应该阻塞，但程序却能顺利执行。而程序2却发生了阻塞。&&&&&更近一步，你能说出执行下面的程序3和程序4会发生什么吗？&&&&/*程序3*/&&&&&&#include&&pthread.h&&&&&&&int&main()&&&&&&{&&&&&&&&&&pthread_rwlock_t&&&&&&&&&&&pthread_rwlock_rdlock(&rwl);&&&&&&&&&&pthread_rwlock_rdlock(&rwl);&&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&return&-1;&&&&&}&&&&&/*程序4*/&&&&&#include&&pthread.h&&&&&&int&main()&&&&&{&&&&&&&&&pthread_rwlock_t&&&&&&&&&&pthread_rwlock_wrlock(&rwl);&&&&&&&&&pthread_rwlock_wrlock(&rwl);&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&pthread_rwlock_unlock(&rwl);&&&&&&&&&return&-1;&&&&&}&&&&在POSIX标准中，如果一个线程先获得写锁，又获得读锁，则结果是无法预测的。这就是为什么程序1的运行出人所料。需要注意的是，读锁是递归锁（即可重入），写锁是非递归锁（即不可重入）。因此程序3不会死锁，而程序4会一直阻塞。&&&读写锁是否可以递归会可能随着平台的不同而不同，因此为了避免混淆，建议在不清楚的情况下尽量避免在同一个线程下混用读锁和写锁。&&&在系统不支持递归锁，而又必须要使用时,就需要自己构造一个递归锁。通常，递归锁是在非递归互斥锁加引用计数器来实现的。&&简单的说，在加锁前，先判断上一个加锁的线程和当前加锁的线程是否为同一个。如果是同一个线程，则仅仅引用计数器加1。&&如果不是的话，则引用计数器设为1，则记录当前线程号，并加锁。关于此的一个实现请参照《》&&需要注意的是，如果自己想写一个递归锁作为公用库使用，就需要考虑更多的异常情况和错误处理，让代码更健壮一些。
阅读(10250) | 评论(1) | 转发(3) |
相关热门文章
给主人留下些什么吧！~~
有一点好像讲错了，按POSIX标准中应该是，在线程申请读锁并未释放前，本线程申请写锁是成功的，但运行后的逻辑结果是无法预测
请登录后评论。