Параллельное программирование тест в GO

Question

Я пытаюсь убедиться, что моя параллельная программа свободна из следующих

• тупиковый
динамический тупик
• голодание

Я нашел следующий инструмент http://blog.golang.org/race-detector

И я попробовал скомпилировать и запустить usin g -race включен и не видел никаких жалоб.

Кто-нибудь знает, проверяет ли это все вышеперечисленные проблемы? Не получает ли жалобы в выходном средстве, чтобы сказать, что в программе нет этих проблем?

Answer 1

IMHO детектор гонки проверяет ничего из вашего списка. Он проверяет достоверность записи в память. (Sidenote: взаимные блокировки Goroutine обнаруживаются во время выполнения.)

Answer 2

Тупик, живое существо и голодание не могут быть устранены путем тестирования в одиночку, и они не обнаруживаются детектором гоночной гонки. Тупики в программах Go будут обнаружены во время выполнения, но, как правило, это слишком поздно. Livelocks (не завершающие петли занятости) не будут обнаружены, если они также не вызывают тупик.

Головоломка с головоломкой похожа на livelock в том, что неуравновешенная занятость в приложении приводит к тому, что некоторые действия будут заглушены и никогда не будут ожидаемого прогресса. Примером может служить знаменитый «Wot no Chickens?» Питера Уэлша.

Сам детектор гонки ограничен в своей полезности, поскольку некоторые условия гонки зависят от окружающей среды, и условия, которые вызывают конкретную гонку, могут отсутствовать на этапе тестирования, поэтому детектор гонки пропустит их.

Если все это звучит довольно мрачно, есть масса теоретической работы, которая может многое помочь. Предпосылка заключается в том, что эти четыре динамические проблемы лучше всего решать с помощью стратегий дизайна и языковых функций, а не путем тестирования. В качестве простого примера язык программирования Occam (который похож на Go в своей модели параллелизма) имеет параллельное правило использования, которое принудительно выполняет компилятор, который устраняет условия гонки. Это накладывает ограничение на программиста: псевдонимы для изменяемого состояния (т. Е. Указатели) не допускаются.

Голосовой голод в Go (и Occam) также должен быть такой же проблемой, как в Java, потому что модель параллелизма лучше разработана. Если вы не злоупотребляете select, это не будет проблемой.

«Тупик» лучше всего обращается к теоретическим шаблонам проектирования. Например, Martin & Welch опубликовал A Design Strategy for Deadlock-Free Concurrent Systems, в котором описана главным образом стратегия клиент-сервер и стратегия i/o-par. Это предназначено для программ Occam, но также относится к Go. Стратегия клиент-сервер проста: опишите свою сеть Go-regular как набор коммуникационных серверов и их клиентов; убедитесь, что в сетевом графике нет петель => тупик устранен. I/O-par - способ создания колец и торов Go-подпрограмм, так что в структуре не будет тупика.