阿里系应用都这个德行

@gantleman 哈哈，小老弟急了。
建议拿你长满老茧的食指把你的百元机屏幕向上滑一滑，看看发帖记录是谁先骂街的吧，还是两三点起夜来骂的噢😁 。
你要是想硬广你这小玩意，好好说话还是可以讨论讨论的。这个态度嘛还是算了吧。
不过还是建议你先把工作找到，这个岁数应该去考虑养老的问题了。
你这账号我就先 block 了，下次你有新的神论了我们再切磋。

@gentleman 论文里的 task 是进程或线程，你这玩意和这篇论文没有半毛钱关系。

拿别人的文章给自己站台前，建议先把全文看完。

还有，我发完贴就直接睡觉了，倒是你自己半夜两三点红着眼爬起来阴阳怪气。

看你 58 楼说自己工作 15 年，估计快 40 了吧。24 小时守着 V2 怼这怼那还挺闲。

再看你 8 天前的发帖记录，“寻找有价值的互联网公司”，看样子兄弟要么是工作不行，要么就是被优化了啊。😂

不要总想着在网上搞大新闻，辣眼睛。

不知道合并 task 是怎么样的一种合并，是在一个线程里来回切换各个 task 吗，还是每个 task 都必须依次完成。
如果是第一种的话事实上解决不了死锁问题。如果熟悉 Linux 用户态 C/C++开发的话你可以尝试写一段测试代码，先 set cpu affinity，把当前进程绑在一个核上，然后起几个使用 mutex 引起死锁的子线程，观察死锁问题是否还存在。
如果是第二种，那其实是把并发执行换成串行执行，也不符合死锁的引发前提。你 quote 的论文的 Introduction 节第一句话是 One of the objectives ...... among many concurrently executing tasks. 在 4 个条件的后一页有对它们的总结: Deadlocks can be expressed more precisely in terms of graphs. Suppose we have a set of tasks { T1, T2, ..., Tn, } in some arbitrary state of execution; ......
你可以理解一下"concurrently executing tasks"、"tasks in some arbitrary state of execution"和你的"task"是否是一个概念。

现在没有劳动合同了，理论上劳动者可以直接走人

一年拍一季，一季看一天

流氓 app 绕过手机权限管理直接从运营商拉手机号码。一直想关了这玩意但不知道电信的该怎么关。

某联上了 SLES，不差钱就是不一样

可能是这些关键词在剪切板礼

还有那种甲方给几百万行，什么都有，时间还错乱的 log 让定位问题的。。总之外包是个大坑

工信部，2 天后营业厅登门道歉，第二天市公司省公司电话道歉，然后就被加进白名单了。

建议等。去年 10 月买了 15 寸，血亏。

说实话挺难的，为什么不能用医保卡购买呢？到 2 月 8 号 9 号的时候如果疫情没有结束那回来上班都困难了。

之我的前接有线网络会有这种现象

给父母买的就是华为的产品，质量是不错。但是坐牢这事没法洗。