Instrukcja select w Go stosuje uniformny, pseudo-losowy wybór, aby zapewnić sprawiedliwość w operacjach komunikacyjnych i zapobiec wygłodnieniu. Gdy wiele przypadków w select jest jednocześnie gotowych, czas wykonania generuje losową permutację kolejności przypadków i ocenia je sekwencyjnie, aż jeden z nich odniesie sukces. Ten projekt gwarantuje, że żaden pojedynczy Kanał nie dominuje wiecznie w wykonaniu, jeśli pozostaje stale gotowy, równomiernie rozdzielając prawdopodobieństwo wyboru pomiędzy wszystkimi gotowymi przypadkami.
Rozważ platformę handlu wysokiej częstotliwości, w której główny Goroutine agreguje dane rynkowe z trzech niezależnych źródeł wymiany. Te źródła dostarczają aktualizacji przez różne Kanały: NYSE, NASDAQ i Forex. Kanał Forex transmituje mikrosekundowe wahania walutowe, podczas gdy NYSE aktualizuje co dziesięć milisekund, a NASDAQ wysyła sporadyczne powiadomienia o dużych blokach handlowych co pięćdziesiąt milisekund w normalnych warunkach.
Jeśli Go oceniłoby przypadki select w stałej kolejności leksykalnej, wieczna gotowość kanału Forex katastrofalnie wygłodziłaby powiadomienia NASDAQ w okresach zmienności handlowej. To wygłodnienie spowodowałoby, że silnik agregacji przegapiłby krytyczne wykonania transakcji, potencjalnie naruszając regulacyjne wymagania dotyczące raportowania najlepszej realizacji. System wymagał mechanizmu sprawiedliwości, który gwarantowałby, że każde źródło danych otrzyma czas przetwarzania, niezależnie od względnej prędkości czy częstotliwości przybycia.
Początkowo rozważaliśmy wdrożenie ręcznego okrężnika, utrzymując rotujący indeks, który cyklowałby przez kanały w naszym kodzie aplikacji. To podejście zapewniałoby deterministyczną sprawiedliwość, śledząc, który kanał był ostatnio obsługiwany i przestawiając kursor zgodnie. Jednak to rozwiązanie wprowadziło znaczną złożoność, wymagając od nas zarządzania wspólnym stanem w dostępie współbieżnym i ukrywając prosty zamiar czekania na wiele Kanałów z czystą składnią.
Drugie podejście polegało na wdrożeniu systemu priorytetów z ważonymi priorytetami, który sztucznie ograniczałby aktualizacje o wysokiej częstotliwości Forex, aby stworzyć pasmo dla wolniejszych kanałów. Choć to pozwoliło na szczegółową kontrolę przezroczystości wiadomości, wymagało ciągłej kalibracji ustawień throttlingu w zależności od warunków zmienności rynkowej. Obciążenie konserwacyjne okazało się zbyt duże, ponieważ błędna konfiguracja mogła cichaczem zrzucić krytyczne ruchy cenowe podczas gwałtownych załamań, gdy system potrzebował surowej przepustowości, a nie równej dystrybucji.
Ostatecznie polegaliśmy na wbudowanym, pseudo-losowym zachowaniu select w Go, które zapewniało statystyczną sprawiedliwość bez złożoności warstwy aplikacji. Równomierny rozkład zapewnił, że na przestrzeni milionów iteracji każdy Kanał otrzymał proporcjonalne możliwości wykonania w stosunku do swojej rzeczywistej częstotliwości gotowości, a nie jej pozycji w kodzie źródłowym. Ten wybór całkowicie wyeliminował wydarzenia wygłodnienia, a nieokreślony charakter zaskakująco pomógł ujawnieniu utajonych warunków wyścigu podczas testów obciążeniowych, które deterministyczne porządkowanie wcześniej maskowało.
Dlaczego Go nie gwarantuje żadnej konkretnej kolejności oceny przypadków select?
Go celowo określa, że wybór między gotowymi Kanałami jest niedeterministyczny, aby zapobiec pisaniu kodu, który zależy od specyficznego porządku implementacji. Czas wykonania może zmieniać swój algorytm losowania między wersjami, więc programy muszą traktować wszystkie przypadki jako równie prawdopodobne, niezależnie od pozycji w źródle. Ta filozofia projektowania zmusza do stosowania solidnych wzorców współbieżności, gdzie Goroutines przypadkowo nie polegają na przypuszczeniach czasowych lub priorytetach kanałów, które mogą przestać działać podczas aktualizacji kompilatora.
Czy można zmusić select do priorytetowania jednego kanału nad innym przy użyciu prymitywów językowych?
Chociaż select w Go jest z natury sprawiedliwy, deweloperzy mogą symulować priorytet, zagnieżdżając instrukcje select lub używając pomocniczych kanałów kontrolnych, choć narusza to idiomatyczny styl Go. Jeden z antywzorów polega na owijaniu szybkich Kanałów z logiką czasu oczekiwania lub używaniem przypadków domyślnych w zajętych pętlach, co prowadzi do oczekiwania na aktywność i marnowania cykli CPU. Prawidłowe podejście akceptuje uniformną losowość jako cechę języka i przekształca architekturę, aby nie wymagać ścisłego priorytetu pomiędzy równocześnie czekającymi Kanałami.
Jaki mechanizm synchronizacji pozwala select czekać na wiele kanałów atomowo?
select rejestruje Goroutine w kolejkach oczekiwania wszystkich zaangażowanych Kanałów jednocześnie przed zaśnięciem, tworząc spójną migawkę stanu oczekiwania. Gdy jakikolwiek Kanał staje się gotowy, budzi Goroutine, która następnie musi konkurować o blokadę, aby kontynuować operację. Ta atomowa rejestracja wiele razy zapobiega zgubieniu przebudzeń i zapewnia, że dokładnie jeden przypadek wykonuje operację, nawet gdy wiele Kanałów odbiera dane jednocześnie, chociaż kandydaci często błędnie wierzą, że select sprawdza lub używa centralnego brokera.