问题描述
我尝试确保我的并发程序不含以下内容：
I'm trying to ensure that my concurrent program is free of the following,
- 死锁
- livelock
- 饥饿
我找到以下工具
我尝试使用 -race 启用编译和运行，没有看到任何投诉。
And I tried compiling and running using -race enabled and did not see any complaints.
有人知道这是否检查所有上述问题？在输出中没有收到任何投诉意味着该程序是免费的这些问题？
Does anyone know whether this checks for all the above issues? Does not receiving any complaints in the output mean to say that the program is free of these issues?
推荐答案
死锁，活锁和饥饿不能通过单独测试消除，它们不会被Go比赛检测器检测到。将在运行时检测到Go程序中的死锁 ，但通常为时已晚。
Deadlock, livelock and starvation cannot be eliminated by testing alone and they are not detected by the Go race detector. Deadlocks in Go programs will be detected at runtime, but then it's usually too late. Livelocks (non-terminating busy loops) will not be detected unless they also cause a deadlock.
线程饥饿与活锁类似，因为应用程序中的不平衡忙碌导致一些活动被阻碍，从未取得预期的进展。一个例子是着名的通过Peter Welch 。
Thread starvation is similar to livelock in that imbalanced busy-ness in an application causes some activities to be stymied and never make the expected progress. An example is the famous 'Wot no Chickens?' by Peter Welch.
赛车检测器本身在其用途方面受到限制，因为一些赛车条件取决于环境，并且导致特定赛程的条件在测试阶段可能不存在，因此比赛检测器将错过他们。
The race detector itself is limited in its usefulness because some race conditions depend on environment and the conditions that cause a particular race may be absent during the testing phase, so the race detector will miss them.
如果这听起来相当暗淡，有一个理论工作，可以帮助很多。前提是这四个动态问题最好通过设计策略和语言特性来解决，而不是通过测试。作为一个简单的例子，Occam编程语言（在其并发模型中非常像Go）具有由编译器强制执行的并行使用规则，消除了竞态条件。这对程序员施加了限制：不允许用于可变状态（即指针）的别名。
If all this sounds rather bleak, there is a body of theoretical work that can help a lot. The premise is that these four dynamic problems are best addressed via design strategies and language features, rather than by testing. As a simple example, the Occam programming language (which is quite like Go in its concurrency model) has a parallel usage rule enforced by the compiler that eliminates race conditions. This imposes a restriction on the programmer: aliases for mutable state (i.e. pointers) are not allowed.
Go（和Occam）中的线程饥饿同样不应该问题，因为并发模型是更好的设计。除非你滥用选择，这不会有问题。
Thread starvation in Go (and Occam) should likewise not be as much a problem as in Java because the concurrency model is better designed. Unless you abuse select, it won't be a problem.
死锁最好由理论设计模式。例如，Martin& Welch发布了，主要描述了客户端 - 服务器策略和i / o-par策略。这是针对Occam程序，但也适用于Go。客户端 - 服务器策略很简单：将您的Go例程网络描述为一组通信服务器及其客户端;确保在网络图中没有循环=>死锁被消除。 I / o-par是一种形成Go程序的环和环的方式，使得结构中不会有死锁。
Deadlock is best addressed by theoretically-based design patterns. For example, Martin & Welch published A Design Strategy for Deadlock-Free Concurrent Systems, which described principally the client-server strategy and the i/o-par strategy. This is aimed at Occam programs but applies to Go as well. The client-server strategy is simple: describe your Go-routine network as a set of communicating servers and their clients; ensure that there are no loops in the network graph => deadlock is eliminated. I/o-par is a way to form rings and toruses of Go-routines such that there will not be a deadlock within the structure.
这篇关于在GO中并发编程测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！