前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >C++核心准则CP.9:尽可能使用工具检查并发代码

C++核心准则CP.9:尽可能使用工具检查并发代码

作者头像
面向对象思考
发布2020-07-02 16:46:26
3490
发布2020-07-02 16:46:26
举报

CP.9: Whenever feasible use tools to validate your concurrent code

CP.9:尽可能使用工具检查并发代码

Experience shows that concurrent code is exceptionally hard to get right and that compile-time checking, run-time checks, and testing are less effective at finding concurrency errors than they are at finding errors in sequential code. Subtle concurrency errors can have dramatically bad effects, including memory corruption and deadlocks.

经验表明,保证并发代码的正确性非常困难,使用编译时检查,运行时检查,测试等方法也不像面对顺序执行代码时那样有效。不易察觉的并发错误可能带来戏剧性的恶果,包括内存破坏和死锁等。

Example(示例)

代码语言:javascript
复制
???
Note(注意)

Thread safety is challenging, often getting the better of experienced programmers: tooling is an important strategy to mitigate those risks. There are many tools "out there", both commercial and open-source tools, both research and production tools. Unfortunately people's needs and constraints differ so dramatically that we cannot make specific recommendations, but we can mention:

线程安全具有挑战性,经常可以打败有经验的程序员:使用工具是减轻这种风险的重要策略。存在很多这方面的工具,既有商用的,也有开源的,既有研究工具,也有生产工具。不幸的是,人们的需要和限制是如此的不同,以至于无法提出特定的建议,但是我们可以进行如下提示:

  • Static enforcement tools: both clang and some older versions of GCC have some support for static annotation of thread safety properties. Consistent use of this technique turns many classes of thread-safety errors into compile-time errors. The annotations are generally local (marking a particular member variable as guarded by a particular mutex), and are usually easy to learn. However, as with many static tools, it can often present false negatives; cases that should have been caught but were allowed.
  • 静态执行工具:无论是clang还是稍旧版本的GCC都对线程安全属性的静态注解提供某些支持。持续地使用这些技术可以将很多类型的线程安全错误转变为编译时错误。这种注解技术通常作用于局部(通过特别的mutex保护特别的成员),一般也容易学习。然而,像很多静态工具一样,它经常会漏报;很多应该抓住的问题会通过检查。
  • dynamic enforcement tools: Clang's Thread Sanitizer (aka TSAN) is a powerful example of dynamic tools: it changes the build and execution of your program to add bookkeeping on memory access, absolutely identifying data races in a given execution of your binary. The cost for this is both memory (5-10x in most cases) and CPU slowdown (2-20x). Dynamic tools like this are best when applied to integration tests, canary pushes, or unittests that operate on multiple threads. Workload matters: When TSAN identifies a problem, it is effectively always an actual data race, but it can only identify races seen in a given execution.
  • 动态执行工具:CLang的线程消毒器(又名TSAN)是动态工具的强有力实例:它修改程序的构建和执行过程以便记录二进制代码执行过程中的内存访问,并识别发生的数据竞争。这么做的代价包括内存方面(大多数情况是5到10倍)和速度方面(2到20倍)。类似的工具特别适用于多线程环境下的结合测试,小规模推送或单元测试。工作负荷问题:当TSAN识别出一个问题,它一定是实际发生的数据竞争,但是只能识别特定的某次执行过程中的竞争。

Enforcement(实施建议)

It is up to an application builder to choose which support tools are for a particular applications.

为一个特定的应用选择合适的支持工具是应用构建的责任。

原文链接

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#cp9-whenever-feasible-use-tools-to-validate-your-concurrent-code

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-06-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 面向对象思考 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Note(注意)
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档