rustconf deadlock

最新推荐文章于 2024-08-30 18:07:11 发布

LinHan_Li

最新推荐文章于 2024-08-30 18:07:11 发布

阅读量301

点赞数

分类专栏：论文阅读文章标签： rust

本文链接：https://blog.csdn.net/weixin_38849460/article/details/120523447

版权

论文阅读专栏收录该内容

20 篇文章 2 订阅

订阅专栏

这篇博客探讨了在Rust中实现互斥锁遇到的挑战，包括对象移动性、错误处理和资源遗忘的安全性。作者提出了parkinglot作为解决方案，它提供更高效的静态互斥锁，并解决了移动性问题。然而，parkinglot的进一步发展遇到了阻碍，如新代码和学术知识的复杂性。文章提到了克服这些挑战的具体步骤，包括稳定性保证、可移动的mutexes和新的操作系统原语的实现。

摘要由CSDN通过智能技术生成

会议记录

chapter 1 problems

之前有标准库，它需要一些同步原语，最重要的就是互斥量，通常是对于某些东西的互斥访问，例如数据或某些其他资源，以便在威胁之间安全的共享它，所以互斥锁是一种在线程间共享某些东西的方法。

原语比互斥锁多，这些现在不重要，重要的是自己实现原语是困难的，锁实现中的错误通常非常微妙，很难找到，他们的错误是非常低级甚至有时特定于架构的代码之间的复杂交互。

在linux Mac 和其他unix上实现了pthread的一部分——pthread_mutex_t，在windos上有srw锁
所以鉴于他们的实现，我们是否可以将它包装起来并完成它，不幸的是，答案是否定的，因为这个是为c设计的，不符合rust的要求，用rust实现时，您会做到很多不同的非常微妙的事情，但这里只强调三个比较大的问题：
（1）如果你在rust中有一个对象，你可以将它移动到内存中的不同位置，这意味着对象在整个生命周期内不能保持在相同的内存地址，但是轻型读写锁的文档中说明锁不允许移动或拷贝，今天的大多数实际实现移动或复制读写锁是可以正常执行的，但是他们的规范或文档根本不允许他这么做，未来的实现可能会以不同的方式工作，因此我们必须遵从这些事实。

因此当作者解决时，将锁分配在堆上，包含在box中——struct Mutex(Box)，实际的底层系统检测并没有发生移动。这个是可以工作的，但是非常的低效，因为这涉及到分配和交互，这意味着我们不能在编译时构造这些对象，所以你不能只拥有一个静态互斥对象，因为需要在运行时分配。（这就是产生低效的原因，因为运行时分配效率低）

（2）rust 对错误的使用必须是安全的，在rust中安全和非安全是有着严格的边界，但在内存安全方面仍然是完全安全的，一个总是恐慌或永远循环的程序，可能只是简单的错误，但他是完全安全的。这里举了一个rust重复上锁的例子，虽然程序是错误的，但是他却是安全的。死锁是安全的！

（3）rust 遗忘事情一定是安全的，这里举了一个锁定了一个互斥区，但是最后忘解锁了，并删除了他，在rust中这也是安全的。

结论：rust不是c，并且在现有事物之上改造rust的所有权和安全概念，rust是与众不同的，试图将c形状的钉子，放入rust形孔并不总是有效的。