Глава 10 Каналы и select on Go: Under the Hood

10.1 Каналы и инженерия CSP

Mon, 01 Jan 0001 00:00:00 +0000

10.1 Каналы и инженерия CSP

К этому разделу прилагается записанный доклад: онлайн на YouTube, презентация в Google Slides.

CSP даёт Go основание утверждать: процессы не разделяют состояние, а координируются исключительно через передачу сообщений (1.3). Настоящий раздел посвящён другому вопросу: чтобы инженерный язык воплотил это утверждение на практике, какую форму должна принять «коммуникация», при которой обычный программист мог бы использовать её корректно. Ответ Go — канал, элемент языка первого класса, являющийся одновременно средством синхронизации и средством передачи данных. Мы начнём с изложения его модели на поверхности языка: тип, синтаксис отправки и приёма, две семантики — буферизованная и небуферизованная, ограничение направления и поведение nil — выстраивая интуицию, которая понадобится последующим разделам при погружении в реализацию рантайма (10.2–10.7).

10.2 hchan: внутреннее устройство канала

Mon, 01 Jan 0001 00:00:00 +0000

10.2 hchan: внутреннее устройство канала

10.1 рассмотрел каналы в языке с позиции CSP: канал — это явный передаточный механизм для сообщений, объединяющий «коммуникацию» и «синхронизацию» в единое целое. Данный раздел разбирает его изнутри. В рантайме канал представлен структурой hchan, весь секрет которой сводится к единственной блокировке, кольцевому буферу и двум очередям ожидания. Структура невелика, однако каждое поле существует по конкретной проектной причине. Стоит уяснить эти немногие элементы — и вся последующая логика отправки, получения и select (10.3–10.6 Модель памяти и эволюция в сторону lock-free) окажется лишь «перемещением данных, парковкой и пробуждением горутин поверх этой единственной картины».

10.3 Отправка, получение и прямая передача

Mon, 01 Jan 0001 00:00:00 +0000

10.3 Отправка, получение и прямая передача

10.2 очертил скелет hchan: мьютекс, кольцевой буфер buf, а также очередь отправителей sendq и очередь получателей recvq. Настоящий раздел оживляет этот скелет и отвечает на вопрос, что именно происходит внутри рантайма при одиночном ch <- v и одиночном v := <-ch. Разобравшись в этом пути отправки/получения, оба наиболее часто задаваемых вопроса о каналах — почему небуферизованный канал является единственной точкой рандеву и почему для него получение происходит прежде, чем завершается соответствующая отправка (11.9), — сводятся к одному механизму: прямой отправке / прямому получению.

10.4 Семантика закрытия канала

Mon, 01 Jan 0001 00:00:00 +0000

10.4 Семантика закрытия канала

В предыдущих разделах операции отправки и получения были «парными» рандеву: одна отправка соответствует одному получению, а избыточная сторона блокируется в ожидании. Закрытие — единственная операция над каналом с семантикой «один ко многим». close(ch) вызывается одной горутиной, однако в тот же момент пробуждает всех получателей, заблокированных на канале, и заставляет немедленно запаниковать всех заблокированных отправителей. Эта возможность «однократного широковещания, пробуждающего всех» превращает закрытие из, казалось бы, малозначимой операции очистки в наиболее распространённый в Go механизм отмены и завершения работы. Паттерн done-канала и отмена через context (11.8) восходят именно к этой семантике.

10.5 Реализация select

Mon, 01 Jan 0001 00:00:00 +0000

10.5 Реализация select

Предыдущие разделы детально рассмотрели отправку и приём данных по одному каналу (10.3). На практике, однако, горутина редко наблюдает лишь один канал: требуется реагировать на первую готовую операцию из нескольких отправок и приёмов и при этом избегать блокировки, если ни одна из них не готова. select создан именно для этого. Его семантика выглядит просто, однако реализация должна одновременно решить две нетривиальные задачи: как справедливо выбрать ветку, когда несколько из них готовы, и как избежать взаимоблокировки при захвате нескольких каналов в рамках одного select. Оба требования определяют всю структуру selectgo, и данный раздел построен вокруг них.

10.6 Модель памяти и эволюция без блокировок

Mon, 01 Jan 0001 00:00:00 +0000

10.6 Модель памяти и эволюция без блокировок

Предыдущие разделы разобрали канал до составных частей: прямая передача в 10.3 позволяет отправляющей и принимающей сторонам передавать значение напрямую, минуя кольцевой буфер, а select в 10.5 делает случайный выбор среди нескольких готовых веток. Эти механизмы объясняют, как канал «работает». Настоящий раздел отвечает на два вопроса более высокого уровня: какую гарантию видимости канал даёт конкурентной программе, и на один инженерный вопрос, который поднимается нередко, — почему канал по сей день остаётся «мьютексом плюс очередью», а не предположительно более быстрой структурой без блокировок. Первый вопрос связывает канал с моделью памяти в 11.9; второй представляет собой реальный компромисс о том, «как корректность и сопровождаемость побеждают пиковую производительность».

10.7 Инженерная практика и межъязыковое сравнение

Mon, 01 Jan 0001 00:00:00 +0000

10.7 Инженерная практика и межъязыковое сравнение

В предыдущих разделах мы разобрали внутреннее устройство канала, пути отправки и получения данных, а также реализацию select на самом низком уровне. Разобравшись в механизме, закономерно встаёт более трудный и практически ориентированный вопрос: когда следует использовать канал, а когда — нет. Слоган Go «не общайтесь через разделяемую память; вместо этого делитесь памятью через общение» легко прочитать как «любое разделяемое состояние должно проходить через канал», но это не то, что имел в виду его автор. Данный раздел сводит этот слоган к конкретному практическому правилу, сопоставляет его с более лёгкими инструментами из главы о примитивах синхронизации (Глава 11), а затем помещает выбор Go в контекст семейства CSP, чтобы понять его конкретные координаты в пространстве проектных решений.