多线程环境中的文档锁定

Document locking in multithreading environment

本文关键字：文档 锁定 环境 多线程      更新时间：2023-10-16

我们有一个支持二进制插件（动态加载库）的应用程序，以及该应用程序的许多插件。应用程序本身是多线程的，插件也可以启动线程。为了保持数据结构的一致性，需要进行大量的锁定。

一个主要问题是，有时从应用程序到插件的调用之间会持有锁。这是有问题的，因为插件代码可能想要回调到应用程序中，从而产生死锁。不同的团队在基础应用程序和插件上工作，这一事实加剧了这个问题。

问题是：除了编写大量的纯文本外，是否还有一种"标准"或至少广泛使用的方式来记录锁定方案？

这是一种理论方法，我希望它能对你有所帮助。

对我来说，你可以通过重新设计插件和应用程序的通信方式来避免这种情况（如果可能的话）。

插件的代码不安全。为了确保应用程序的灵活性和稳定性，您必须建立一种标准的方式来交换信息，并使用插件进行关键操作。

最简单的方法是通过定义一个无锁api来避免管理每个特定的插件行为。要做到这一点，您可以通过使用环形缓冲区/中断器或仅使用操作缓冲区来使插件的关键部分异步。

编辑

很抱歉，如果我再次以同样的方式争论，但在我看来，这就像是一个"IO"问题。

您可以同时访问某些资源（内存/磁盘/网络……不知道是哪些），并且需要以高可用性公开这些资源。最后，如果不锁定应用程序，就无法随机访问这些资源。

有了一位专注于关键部分的经理，等待的时间可能会短到让人察觉不到。

然而，这并不容易适用于现有的应用程序，尤其是在大型应用程序的情况下。

如果你还不知道这类东西，我鼓励你去寻找"颠覆者"。对我来说，这是我每次使用线程时都要考虑的现代基本问题之一。

我建议使用Petri网，它学习起来很简单，可以很好地描述软件不同部分之间的合作。在这个问题中，描述了几个对文档并发性有用的模型和工具：https://stackoverflow.com/questions/164187/what-tools-diagrams-do-you-use-for-modelling-multithreaded-systems.你可以根据自己的需要选择合适的型号。

如果您的锁定方案足够简单，您可以在文档中描述它，那么无论如何都要这样做。但是，如果在实践中发生死锁，问题可能不是缺少文档，而是API无法满足插件作者的需求。记录限制是很好的第一步，但消除限制更好。

考虑由代码持有并由插件请求的单个锁上死锁的可能性：

  1. 您的代码没有处于读取或写入过程中，但仍然持有锁，因为这就是代码的编写方式。在这种情况下，您的代码应该在调用插件之前释放锁
  2. 您的代码和插件都在读取数据，并使用锁来防止并发编写器。在这种情况下，请使用读写器锁
  3. 您的代码正在更改数据，并且插件想要读取它。这通常是不安全的；毕竟，使用锁来保护整个修改是有原因的。大多数实现这种安全的尝试在实践中都失败了（这就像编写无锁代码一样困难）。在这种情况下，最好的做法是更改您的设计，以便您的代码在调用插件之前完成更改，或者在调用插件之后开始更改
  4. 您的代码正在读取数据，插件想要更改它。与前面的情况一样，这也是不安全的。您的代码应该在调用插件之前释放锁，然后再次获取它，并假设数据已经更改，重新读取任何需要继续的内容

这是我在不了解您的申请及其具体需求的情况下能给出的最好建议。

对于大多数应用程序，软件公司在同一过程中都会回避第三方二进制插件，因为当出现问题时，很难找出原因。用户通常会责怪应用程序，而不是插件，并且对应用程序质量的感知很差。它可以通过与插件作者保持非常密切的关系来发挥作用，通常包括交换所有源代码（可选地在限制性许可证或NDA下）。

是的，有一种标准的方法可以记录大学中使用的锁定方案。1/使用图你必须画一张图表。图上的每个点都是到其他线程的锁定链接。

ex: T1      T2
     1 -R->  A
     2 <-W-  B

2/使用表格你必须在每行上写下每个点和线程

ex:  T1         T2
     lockX(A)   lockS(B)
     read(A)    read(B)
     A<-A50     unlock(B)

结论：这是一项非常复杂的任务，需要花费大量时间进行追踪。

相关文章：