哲学家就餐问题的一个解法

2023-02-17 20:45:42 +08:00
 movq

阻塞 lock 拿到一个筷子后,非阻塞 tryLock 另一个筷子。如果得不到,就把手里的筷子释放掉

这样感觉也可以解决

网上搜了下貌似没看到有人写这种解法?

2332 次点击
所在节点    程序员
28 条回复
bxb100
2023-02-17 21:01:55 +08:00
有没有种可能死锁之外还有个叫活锁的概念
dcsuibian
2023-02-17 21:37:29 +08:00
早就有人说了吧。
死锁的四个条件:禁止抢占、持有和等待、互斥、循环等待
这不就是破坏“持有和等待”么?
lessMonologue
2023-02-17 22:11:11 +08:00
。。。。。
如果每个人同时拥有一个筷子呢?
xyjincan
2023-02-17 22:12:49 +08:00
死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。死锁需要必要的条件才能产生,下面为大家介绍死锁的四个必要条件。

产生死锁的四个必要条件

   1 、互斥条件:一个资源每次只能被一个进程使用;

   2 、请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放;

   3 、不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺;

   4 、循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系;

这个相当于放弃 2 这个必要条件
shawnsh
2023-02-17 22:16:20 +08:00
@bxb100 当然有活锁了。只消耗 CPU ,不干事情。比死锁更消耗资源
hhjswf
2023-02-17 22:23:29 +08:00
这都主动释放锁还谈死锁有什么意思
movq
2023-02-17 22:44:44 +08:00
@lessMonologue 拥有一个筷子拿不到别的不就释放了吗,这样别的线程就可以拿到了
movq
2023-02-17 22:46:45 +08:00
@bxb100 没抢到锁就设置随机睡眠时间应该可以吧
movq
2023-02-17 22:48:35 +08:00
@dcsuibian 你说的这个几个条件属于比较抽象的,我看了下 Wikipedia 和 Google 头几条,具体的例子里面貌似没人提到这个,就来问下大家什么看法
lessMonologue
2023-02-17 22:49:36 +08:00
@movq 那如果这个拿起-阻塞-释放的过程一直在持续下去呢? 如果你设置的随机睡眠时间,每一次都相同呢?
movq
2023-02-17 22:53:18 +08:00
@shawnsh 感觉活锁的危害性是没死锁大的。如果进入了死锁,除非杀掉某个线程,不然解决不了问题。而活锁属于概率性问题。CPU 调度线程往往不会这么凑巧。调度差几个时钟周期就可以跳出活锁。应该不会持续太久。
movq
2023-02-17 22:54:29 +08:00
@lessMonologue 为什么我设置的随机睡眠时间会每次都相同呢?那这个只能问是不是有这么弱的标准随机数库了
lessMonologue
2023-02-17 22:57:14 +08:00
@movq 恰恰相反。准确来说,应该是“无法稳定复现但常常出现的活锁问题比死锁更为严重”。解决死锁只需要破坏 4 个条件之一,而能写出存在活锁现象代码的人,根本不会考虑随机时间的问题。
movq
2023-02-17 23:04:31 +08:00
@lessMonologue 你的主张比较牵强
movq
2023-02-17 23:11:56 +08:00
@lessMonologue

你一边声称「懂得怎么避免死锁的人可以避免死锁」,然后又说「不懂活锁现象的人考虑不到随机时间」。

逻辑漏洞太多:
1. 这两句话跟活锁死锁哪个更严重根本就毫无关联。
2. 前后两句话本身也毫无关联,不懂在一起说想表达什么。

对 2 的证明:
「懂得怎么避免死锁的人可以避免死锁」,并不能否定「懂得怎么避免活锁的人也会考虑到随机时间」

对 1 的证明:
懂不懂得死锁活锁,只是一个专业知识的问题,和活锁死锁哪个严重,毫无关联,是在偏离讨论的问题。
movq
2023-02-17 23:15:48 +08:00
@lessMonologue 这么说吧,不知道你哪来的莫名的优越感。

一开始你根本没看懂我在说什么,就打几个逗号表示无语,说每个人拿个筷子就能反驳我这种做法。结果反而让自己成了小丑。

后来又强行说什么「如果随机事件恰好相同呢?」这种脑残假设

我反驳之后又来信口开河说什么“恰好相反”,结果你对你的主张的论证漏洞百出

真是笑死人
movq
2023-02-17 23:20:16 +08:00
我总结一下死锁和活锁的对比,以下来自于《 C++ Concurrency in Action 》

1.死锁没法救活,除非编程时就避免。这一点活锁有优势,因为活锁就算你编程时不避免,由于 CPU 的调度存在一定的偏差,也有可能可以自行脱离活锁。(可以看引用的“not-so-serious cases”)
2.死锁发生时因为是等待,所以不会自旋,不占 CPU ,这方面是比活锁好的。


> Deadlock - As you saw in chapter 3, in the case of deadlock, one thread is waiting for another, which is in turn waiting for the first. If your threads deadlock, the tasks they're supposed to be doing won't get done. In the most visible cases, one of the threads involved is the thread responsible for the user interface, in which case the interface will cease to respond. In other cases, the interface will remain responsive, but some required tasks won't complete, such as a search not returning or a document not printing.

> Livelock - Livelock is similar to deadlock in that one thread is waiting for another, which is in turn waiting for the first. The key difference here is that the wait is not a blocking wait but an active checking loop, such as a spin lock. In serious cases, the symptoms are the same as deadlock (the app doesn't make any progress), except that the CPu usage is high because threads are still running but blocking each other. In not-so-serious cases, the livelock will eventually resolve because of the random scheduling, but there will be a long delay in the task that got livelocked, with a high CPU usage during that delay.
Nerv
2023-02-17 23:38:29 +08:00
死锁的四个条件维基百科不是明明白白的给列出来了吗。这种操作浪费计算资源,同时要考虑到如果对第一只“筷子”做出了修改,还需要进行相应的恢复流程。
这种在计算机发展初期就有的大问题,肯定是被大佬们研究烂了,思而不学不可取。
movq
2023-02-17 23:45:50 +08:00
@Nerv 来 v 站发帖不就是为了看大家意见从而学习吗?光思考的话为什么要发帖子呢?我认为自己是对的不就行了
movq
2023-02-17 23:46:47 +08:00
@Nerv 那你的意思是对凡是已经有定论的的东西都绝对不要提出个人想法是么

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/917039

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX