Спасибо за размышления! Из личного опыта мысль про редкость использования относится в основном к pthread барьерам, остальные примитивы используются почти повсеместно. Вероятно оттого что данный примитив не так сильно распространен и используется для ограниченного круга задач. Встречались различные вариации других примитивов явно напоминающие использование барьера, например, счетный вариант (EFD_SEMAPHORE) eventfd или сами семафоры в чистом виде.
Не полностью понял часть комментария про примитивы С и основу ОС. Про привязку примитивов синхронизации к ОС вопрос достаточно обширный только потому что у Golang необходимо их рассматривать как часть рантайма: там в целом очень большое число оптимизаций для того чтобы избегать накладных расходов в вызовы ОС и обходиться поддержкой уровня горутин. Сам golang в чистом виде не использует вызовы С для имплементации примитивов синхронизации (системные вызовы, например, futex тут не рассматриваю). Но основа так или иначе это одна - ОС которая предоставляет основные возможности для базовых операций.
UPD: спасибо! был один и тот же код, поправили. Сейчас актуальный вариант. Для блокирующего варианта используется простой вызов accept(), для неблокирующего варианта уже accept4 с флагом SOCK_NONBLOCK дополнительно обернутый в do/while для разрешения ситуации с EAGAIN.
Обычный простой sleep или вариации smart sleep из области мультиплексирования (select/poll/epoll)?
Спасибо за размышления!
Из личного опыта мысль про редкость использования относится в основном к pthread барьерам, остальные примитивы используются почти повсеместно. Вероятно оттого что данный примитив не так сильно распространен и используется для ограниченного круга задач. Встречались различные вариации других примитивов явно напоминающие использование барьера, например, счетный вариант (EFD_SEMAPHORE) eventfd или сами семафоры в чистом виде.
Не полностью понял часть комментария про примитивы С и основу ОС.
Про привязку примитивов синхронизации к ОС вопрос достаточно обширный только потому что у Golang необходимо их рассматривать как часть рантайма: там в целом очень большое число оптимизаций для того чтобы избегать накладных расходов в вызовы ОС и обходиться поддержкой уровня горутин. Сам golang в чистом виде не использует вызовы С для имплементации примитивов синхронизации (системные вызовы, например, futex тут не рассматриваю).
Но основа так или иначе это одна - ОС которая предоставляет основные возможности для базовых операций.
UPD: спасибо! был один и тот же код, поправили. Сейчас актуальный вариант.
Для блокирующего варианта используется простой вызов accept(), для неблокирующего варианта уже accept4 с флагом SOCK_NONBLOCK дополнительно обернутый в do/while для разрешения ситуации с EAGAIN.