Посмотрите на это утверждение, взятое из Примеры из оригинального документа 1978 года Тони Хоара:
На дизайн Go сильно повлияла бумага Hoare. Хотя Go значительно отличается от языка примера, используемого в документе, примеры по-прежнему довольно легко переводятся. Самая большая разница, кроме синтаксиса, заключается в том, что Go моделирует каналы параллельной связи явно как каналы, тогда как процессы языка Hoare отправляют сообщения напрямую друг другу, подобно Erlang. Хоар намекает на эту возможность в разделе 7.3, но с ограничением на то, что "каждый порт подключен точно к одному другому порту в другом процессе", и в этом случае это будет в основном синтаксическим различием.
Я смущен.
Процессы на языке Hoare общаются напрямую друг с другом. Go также взаимодействуют напрямую друг с другом, но используют каналы.
Так какое влияние имеет ограничение в golang. Какая разница?
Точно так: на языке примера, используемом в первоначальной работе Hoare (а также в Erlang), процесс A ведет непосредственно к процессу B, тогда как в Go горутин A разговаривает с каналом C, а goroutine B слушает канал C. I.e. в Go каналы явны, в то время как в языке Hoare и Erlang они неявны.
Подробнее см. в этой статье.
Ответ требует более полного понимания работы Хоара в CSP. Прогресс его работы можно обобщить в три этапа:
основанный на семафоре Дейкстры, у Хора были развитые мониторы. Они используются в Java, но реализация Java содержит ошибку (см. Статью Welch Wot No Chickens). Это печально, что Java проигнорировал Хоар позже.
CSP вырос из этого. Первоначально CSP требовал прямого обмена от процесса A до процесса B. Этот подход рандеву используется Адой и Эрланом.
CSP был завершен к 1985 году, когда Законы оккамского программирования). В течение многих лет Occam был доступен только на процессоре Transputer, который имел свою архитектуру, адаптированную под CSP. Совсем недавно Оккам разработал, чтобы нацелить другие процессоры, а также поглотил Pi-исчисление вместе с другими примитивами общей синхронизации.
Итак, чтобы ответить на исходный вопрос, вероятно, полезно сравнить Go с CSP и Occam.
Каналы: CSP, Go и Occam имеют одинаковые семантики для каналов. Кроме того, Go упрощает добавление буферизации в каналы (Оккам не работает).
Выбор: CSP определяет как внутренний, так и внешний выбор. Однако оба варианта Go и Occam имеют один вид выбора: выберите в Go и ALT в Оккаме. Тот факт, что есть два вида выбора CSP, оказался менее важным на практических языках.
Оккам ALT позволяет защищать состояние, но Go select не работает (есть обходной путь: псевдонимы каналов могут быть установлены на nil, чтобы имитировать одно и то же поведение).
Мобильность: Go позволяет отправлять концы каналов (вместе с другими данными) по каналам. Это создает динамически меняющуюся топологию и выходит за пределы возможностей CSP, но для определения таких сетей был разработан (из его CCS) метод Milner Pi calculus.
Процессы: Горотин - это разветвленный процесс; он заканчивается, когда захочет, и у него нет родителя. Это меньше похоже на CSP/Occam, в котором процессы являются составными.
Пример поможет здесь: во-первых, Оккам (n.b. отступы)
SEQ
PAR
processA()
processB()
processC()
и, во-вторых, Go
go processA()
go processB()
processC()
В случае Occam processC не запускается до тех пор, пока не прекратятся как processA, так и processB. В Go, processA и processB fork очень быстро, затем processC запускается сразу.
Общие данные: CSP напрямую не связан с данными. Но интересно отметить, что существует важное различие между Go и Occam относительно общих данных. Когда несколько goroutines имеют общий набор переменных данных, возможны условия гонки; Отличный детектор гонки помогает устранить проблемы. Но Occam принимает другую позицию: во время компиляции предотвращаются общие изменчивые данные.
Псевдонимы: связанный с вышеперечисленным, Go позволяет многим указателям ссылаться на каждый элемент данных. Такие псевдонимы запрещены в Оккаме, поэтому уменьшаются усилия, необходимые для обнаружения условий гонки.
Последние два пункта меньше о Hoare CSP и о May Occam. Но они актуальны, потому что они непосредственно касаются безопасного одновременного кодирования.