我们已经准备好了,你呢?

2022我们与您携手共赢,为您的企业形象保驾护航!

我是一个线程,一个卖票程序的线程。

自从我们线程诞生以来,同一个进程地址空间里允许有多个执行流一起执行,效率提升的同时,也引来了很多麻烦。

我们卖票线程的工作很简单,比如票的总数是100,每卖一张就减1,直到变成0售完为止。

以前单线程的时候没啥问题,但多个线程一起执行的时候就发现,有些家伙读取到票数是100,减1后变成99,还没等他把票数写回去,另外有别的线程去读也是100,也做了同样的事,结果卖了两张票,票数才减了1张,一天下来,多卖了很多票,气的人类差点想砸了我们。

原子操作

我们把这问题反馈给了操作系统大哥,他给我们的解决方案是:读取票数->票数减1->写回票数这三个步骤不能被拆分,中途不能被打断,他说这个叫原子操作

他给了我们一套原子操作的手册,里面不止有减法,还有加法、位运算,只要调用手册里的原子操作函数,就能保证逻辑的正确性。

我很好奇操作系统大哥是如何实现这个过程的原子化的,他告诉我,如果CPU只有一个核很好办,执行原子操作的时候,他不切换线程就可以。而如果是有多个核,就需要CPU来帮忙了。

你还别说,我们用这个原子操作来卖票后,再也没有发生超额卖票的问题。

自旋锁

有一天,我们卖票程序进行了升级,不再是直接读取票数->票数减1->写回票数这么简单,还需要安排座位,现在变成了:

 我们一翻手册,没有哪个原子操作函数能满足我们的功能,毕竟安排座位这个操作是咱们卖票程序自己的事儿,一点也不通用,操作系统大哥肯定不会专门为我们开发一个原子操作函数。

我们只好再一次求助操作系统大哥,他一看就说:“你们这个问题,用自旋锁就可以解决”

锁?我们还是第一次听说这玩意,不知道是什么意思。

操作系统告诉我们,让我们回去创建一个锁,这锁里面有一个状态标记来表示当前有没有被占用,所有线程在执行卖票操作之前,都得先去获取这个锁,如果锁被占用了,线程就会阻塞在获取函数那里,获取函数内部会不断循环去检查,直到别的线程释放后才返回。

 因为获取锁的时候线程会一直循环检查状态,所以这锁也叫自旋锁。

现在,我们的工作流程变成了:

我们又可以愉快地卖票了!

互斥锁

我们的业务发展很快,后来,我们用上了数据库,把票的数量写到了数据库里面,于是我们的工作流程变成了:

 本以为只是把票数从本地内存搬到了数据库,应该没什么不一样,结果发现我们运行经常出错,还莫名其妙地被杀掉进程。

我们向操作系统大哥大倒苦水,没想到他却说:“你们还好意思诉苦,你们获取自旋锁后搞那么耗时的操作,让别的线程一直自旋等待,把CPU都跑得飞起,风扇都转个不停···”

我们都羞愧地低下了头,原来,把票数从本地内存搬到了数据库,差别这么大。

操作系统又接着说道:“自旋锁因为会使得线程一直阻塞自旋,没有让出CPU,所以只适合处理比较快速的场合,像读取数据库这种很耗时的操作,不能用它,会白白浪费CPU时间!”

我们又询问:“有没有别的不浪费CPU的办法呢?”

操作系统大哥又给我们介绍了一个叫互斥锁的东西,听说获取这个锁的时候,线程不会去自旋检查,而是把自己放到这把锁的等待队列中,然后就交出CPU执行权限,进入睡眠,看起来就跟阻塞一样,等到后面别的线程释放锁之后,再去唤醒它的等待队列里的线程继续运行。

回去以后我们就用上了互斥锁,现在我们的流程变成了这样:

 我们又又能愉快地卖票了!

条件变量

有一天,我们的卖票程序又进行了升级,21-100号票价格比较便宜,交给其他线程来卖,1-20号票价格比较贵,交给我来卖。

现在,我们不同的线程卖的票不一样了。

别的线程的流程是这样:

 而我的流程是这样:

 使用互斥锁倒也没什么问题,可就是我经常拿到锁以后发现票号还大于20,不该我处理,只好默默的释放锁,白白把我唤醒,却什么也没干!

空手而回的次数多了以后,我又去请教操作系统大哥,能不能让我指定一个条件,等条件满足了再唤醒我运行,别让我白跑。

没想到还真有办法!操作系统告诉了我一个叫条件变量的东西,等待条件变量的线程平时阻塞着,别的线程发现条件满足之后,就将条件变量激活,那个时候等待的线程才会被唤醒。

回去之后,我跟我的小伙伴儿们商量了一下,我们创建了一个条件变量,等到它们发现票号小于等于20的时候,就把条件变量激活,我就会被唤醒,再也不用白跑了!

信号量

互斥锁和条件变量真是好东西,帮了我们大忙,不仅帮我们解决了卖票的问题,我们还在其他很多地方使用它,我们遇到的绝大多数同步和互斥问题都可以用它们来解决。

直到有一天,我们遇到了一个新的问题。

我们的票越卖越好,从100到1000,票的数量越来越多,来找我们买票的客户也越来越多。

因为每次售票都要访问数据库,连接它的线程有些多,那家伙有些吃不消了。

希望我们控制一下访问数据库的线程数量。

我们很自然的想到了互斥锁,只有拿到锁的线程才能去访问数据库。

可这互斥锁名叫互斥,只能允许一个线程拿到锁,总不能只允许一个线程访问数据库吧,那可不行。所以我们希望这个名额能放宽,允许多个线程同时获得锁。

我们再一次找到了操作系统大哥,大哥拿出了他的绝招——信号量

他告诉我们,这信号量就像一个升级版的互斥锁,它里面有一个计数器,可以用来指定最多允许多少个线程同时获得它。

这正是我们想要的锁!

很快我们用上了信号量,我们又又又能愉快地卖票了!

Tips:在信号量一节中,实际上数据库能承受的并发量远不止这点,这里为了故事情节需要,弱化了数据库的并发承受能力。


我们凭借多年的网站建设经验,坚持以“帮助中小企业实现企业数字化转型”为宗旨,得到了客户的一致好评。如果您有软件开发、网站建设、网站改版、域名注册、主机空间、手机网站建设、网站备案等方面的需求...
请立即点击咨询我们,我们会详细为你一一解答你心中的疑难。点击立即沟通

我们已经准备好了,你呢?

让我们与您携手共赢,为您的企业形象保驾护航!

在线客服
联系方式

上班时间

周一到周六 9:30-17:30

公众号

冰橙文化科技

公众号二维码
线
在线留言