请选择 进入手机版 | 继续访问电脑版

HTML5星空

编程世界的那把锁

[复制链接]
发表于 2017-8-1 00:10:03 | 显示全部楼层 |阅读模式

来自:码农翻身(微信号:coderising)


共享变量惹得祸


我们这里是个典型的弱肉强食的世界, 人口多而资源少,为了争抢有限的资源,大家都在自己能运行的CPU时间片里拼了老命,经常为了一个变量的修改而打的头破血流。


100纳秒以前, 我有幸占据了CPU,从内存中读取了一个变量x == 100, 我把它加了1, 休息了一会儿后我打算把它写回内存, 但是惊奇的发现: 内存中的x 已经变成102了。


估计是哪个不着调的线程在我休息的时候也读取并且修改了x,   有不少好心的线程在冲我喊:不要写回了! 但是写回内存是我的指令啊, 你不让我执行,难道让我退出?  我只能毫不客气的把101写入内存, 把那个不符合我逻辑的值102给覆盖掉, 这样我才能执行下一条指令。


你看,单线程的逻辑正确并不表示多线程并发运行时的逻辑也能正确。 


这样的事情发生的多了,程序总是无法正确运行, 引起了人类的强烈不满,小道消息说他们在考虑kill掉我们, 换编程语言了。


但是换编程语言有什么用,只要有共享变量,多线程读写的时候就是会出现不一致啊。


除非你消除共享变量,让每个线程只访问一个函数内的局部变量, 这些局部变量我们每个线程都会有一份, 函数结束以后就会销毁,所以线程之间就隔离了,就安全了。


消除共享变量谈何容易, 人类使用的很多语言例如C++, Java,那些共享变量大多数一个对象的字段, 你想把字段去掉, 只留下函数, 那类也没有存在的必要了, 就类似于函数式编程了, 一切都是函数。  有时候我挺羡慕函数式的世界, 那种无状态应该是一种非常美妙的感觉吧。


2争抢吧,线程


既然共享变量是无法消除的,那就想想别的办法吧, 线程元老院的那帮家伙们哼哧了半天,终于公布了一个方案: 加锁!


任何线程,只要你想操作一个共享变量,对不起, 先去申请一把锁, 拿到这把锁才能读取x的值 , 修改x的值,  把x写回内存, 最后释放锁,让别人去玩。


元老院设计的这把锁非常简单, 类似于一个boolean 变量, boolean lock = false.       谁能抢先把这个变量改成true, 就意味着获取了这把锁。


来吧,哥几个,快来抢吧 !


我运行的时候, 就去检查lock这个变量是否可以设置为true, 如果被别的家伙给抢到了(已经变成true了), 我就在这里无限循环,拼命的抢, 除非我的时间片到了,被迫让出CPU, 但是我不会阻塞, 还是就绪状态,等待下一次的调度, 进入CPU继续抢。


看到某人把它变成false, 我眼疾手快迅速出手, 终于抢到了,赶紧把lock改成true, 这把锁现在属于我了, 赶快去干活,干完活要记住把lock 改成false,  让别的家伙们去抢。


我想正是由于这种无限循环的特点, 元老院把他命名为“自旋锁”吧!


列位看官,可能你已经想到了, 假设有两个线程,都读到了lock == false,  都把lock 改成true, 那这个锁算谁的?


这个问题元老院的大佬们早就考虑到了, 他们和操作系统(我听说还有硬件)都商量好了, 这个检测lock是否为false, 以及设置lock 为true 的操作 其实被合并了, 叫做test_and_set(lock),  操作系统郑重承诺,这是一个不可分割的原子操作, 在这个test_and_set执行的时候,总线都被锁住了, 别人不能访问内存, 即使有多个CPU在执行也不会乱掉。


如果你感兴趣,可以看看下面的实现, 否则直接无视跳过:



3改进


有了自旋锁, 至少可以保证程序的正确运行了, 我们大家都玩的不亦乐乎。


有一天我遇到了一个递归函数, 我是挺喜欢递归的, 因为逻辑简单, 只要递归的层次别太深, 别搞出栈溢出就好。  


这个递归函数中需要获得自旋锁,做点事情, 然后继续调用自己, 类似于这样:



我第一次调用doSomething, 获取了自旋锁, 然后第二次调用doSomething, 还要获取自旋锁,  可是这个锁已经在我第一次调用的时候持有了, 现在第二次调用只有无限的等待了! 


这下尴尬了, 我进退不得, 自己把自己搞成了死锁!


看来这个自旋锁虽然能实现互斥的访问, 但是不能重新进入同一个函数(简称不可重入)啊!


我赶紧把这个问题向元老院做了汇报, 修改方案很快就下来了: 每次成功的申请锁以后,要记录下到底是谁申请的, 还要用一个计数器记录重入的次数, 下一次持有锁的家伙再次申请锁只是给计数器加一而已。


释放的时候也是一样, 把计数器减一, 如果等于0了才真正的释放锁。


可重入性就这么解决了, 但是这么多线程都在那里拼命的抢也不是办法, 空耗CPU也是巨大的浪费啊。


于是元老院又发布了新的锁 ReentrantLock, 这个锁可以重入,如果你抢不到, 不要无限循环了, 乖乖的到等待队列里待着去, 等到锁被别人释放了再通知你去抢。


(在Java 中最初是synchronzied关键字,可以用在一个方法上或者一个代码块上, 后来又改进为更加灵活的ReentrantLock)


很快就有线程还抱怨说, 明明是我先发出获得锁的申请啊, 为什么隔壁老王却先拿到了锁? 这不公平啊,不行,以后得排队, 先来先得。   好吧, 只好加上一个是否公平的参数。


还有线程说, 我是个急性子,申请锁的时候只想等待5秒钟, 5秒之内得不到锁我就放弃了, 能不能支持?  那就再加上一个参数:等待时间。


4发扬光大


体会到锁带来的甜头以后, 各种各样样的需求纷至沓来: 


1. 有时候需要多个线程都获得同一把锁,去做一件事情,那怎么办呢?


没关系,信号量(Semaphore)出马,创建信号量的时候得指定一个整数(例如10), 表明同一时刻最多有10个线程可以获得锁: 

Semaphore lock= new Semaphore(10);


当然每个线程都需要调用lock.aquire(), lock.release()去申请/释放锁。 


2.  一个线程要写共享变量, 可是还有几个线程要同时读, 怎么办? 你写的时候可以锁住, 但总不能读的时候也只允许一个线程吧?  


只好来一个读写锁了ReadWriteLock, 为了保证可重入性, 元老院体贴的实现了ReentrantReadWriteLock。


 3. 一个线程需要等待其他多个线程完工以后才能干活,怎么办? 


CountDownLatch前来救驾, 搞一个计数器,某个线程干完了就把计数器减去1, 如果计数器为0了,那个一直耐心等待的线程就可以开始了。


4. 还有几个线程必须互相等待, 就像100米赛跑那样, 所有人都准备好了才能开闸放水, 不,是起跑, 就那就赏你一个CyclicBarrier吧。


来自:码农翻身(微信号:coderising)



●本文编号451,以后想阅读这篇文章直接输入451即可。

●输入m获取文章目录

推荐↓↓↓
 

Python编程

更多推荐18个技术类公众微信

涵盖:程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快讯
发布主题 快速回复 返回列表

     京ICP备14042305号

html5star team © 2012-2013 html5星空 Comsenz Inc.

GMT+8, 2018-12-14 04:26 , Processed in 0.234496 second(s), 37 queries .

快速回复 返回顶部 返回列表