4

作为一个刚刚在一个项目中完成了数千行复杂的多线程“C”代码的开发人员,并且将来会被其他几个不熟悉该代码的开发人员增强、修改等,我想找出你们试图在这样的代码中放置什么样的安全网?例如,我可以这样做:

  1. 为锁保护结构成员定义访问器宏,它断言相应的锁已被持有。这清楚地表明,对于不熟悉此代码的任何人,这些成员都受到锁定保护。
  2. 应该在持有一些自旋锁的情况下调用的函数断言正在持有自旋锁。

您在编写的多线程代码中设置了什么样的安全网?
当其他开发人员修改此类代码时,您遇到过什么样的问题?
您在此类代码中添加了哪些调试辅助工具?

感谢您的意见。

4

3 回答 3

5

我们在我们的产品(旨在帮助您发现应用程序中的并发错误的虚拟机管理程序)中做了很多更普遍有用的事情。请注意,我们在代码本身中执行这些操作(因为它是一个高度并发的软件),并且无论您是否正在编写并发代码,其中一些都是有用的。

  • 像你一样,我们有能力断言(lock_held(...)) 并使用它。

  • 我们也(因为我们有自己的调度程序)可以断言(single_threaded())对于那些(罕见的)我们指望系统中没有其他线程处于活动状态的情况。

  • 从一个线程到另一个线程的内存损坏非常普遍(并且难以调试),因此我们做了两件事来解决这个问题:在我们的线程堆栈中散布一些神奇的 cookie。我们定期(在我们的 get_thread_id() 函数中)调用“validate_thread_stack()”函数来检查这些 cookie 以确保堆栈没有损坏。

  • 我们的 malloc 在 malloc 内存块之前和之后粘贴魔术饼干,并免费检查这些。如果有人超出了他们的数据,这些可以用来及早发现损坏。

  • 在 free() 上,我们在内存中爆炸了一个众所周知的模式(在我们的例子中是 0xdddd...)。这很好地破坏了将悬空指针留在该内存区域的任何其他人。

  • 我们在线程堆栈底部附近有一个保护页面(未映射到地址空间的内存页面)。如果线程超出其堆栈,我们通过页面错误捕获它并放入我们的调试器。

  • 我们的锁被见证了。查看 FreeBSD 锁定见证代码。就像那样,但自制。基本上,见证代码是一种通过查看锁获取图中的循环来检测潜在死锁的轻量级方法。

  • 我们的锁也包裹着访问器,记录获取和释放的文件/行号。对于双重解锁或双重锁定,您将获得有关您的错误的漂亮调试信息。

  • 我们的锁也有轮廓。一旦你让你的代码工作,你希望它运行良好。我们跟踪通常的事情,比如有多少收购,收购需要多长时间。

  • 在我们的系统中,我们期望锁不会被争用(我们以这种方式精心设计了代码)。因此,如果您在我们的系统中等待自旋锁的时间超过一两秒,您就会被放入调试器中,因为这很可能不是一件好事。

  • 我们打算以原子方式更新的变量被包装在 C 结构中。这样做的原因是为了防止你混合使用的草率代码: atomic_increment(&var); 和不好的使用 var++。我们很难编写后面的代码。

  • “volatile”在我们的代码库中是被禁止的,因为它被编译器模糊地实现了。这是尝试拼凑同步的一种不好的方法。

  • 当然还有代码审查。如果您无法向同事解释您的并发假设和锁定规则,那么代码肯定存在问题 :-)

于 2010-01-07T00:49:15.957 回答
2

让一切都变得一目了然,这样其他开发人员在单独查看代码的子部分时就不会错过同步范围。

例如:不要锁定跨越多个文件的代码。

于 2010-01-06T22:21:49.137 回答
1

似乎您已经回答了自己的问题:将大量断言放入代码中。他们将告诉其他开发人员必须具备哪些不变量和先决条件。

于 2010-01-06T22:19:10.203 回答