в таком случае буфер это кол-во звонков которые колл центр может держать параллельно

хотяя

хз это как то сложно

Зачем эти параллели? В один прекрасный момент параллель не сойдётся с реальностью, а в голове будет старая ассоциация...
Так, люди из других языков проповедуют нереальные вещи на основе своего прошлого опыта, потому что когда-то себе выстроили систему ассоциаций, хотя даже базовые вещи такие как массив и хешмапа работают очень по-разному.
По топику датарейса с счётчиком наиболее оптимальным был бы atomic, вообще схем работы при датарейсе много и каналы, например тут довольно много кода требуют

Так мы вроде вообще не про датарейсы говорили

Только ошибок столько же как с мьютексами ))

Лучше всё-таки не забивать голову аналогиями и описывать в модели producer-consumer:

spsc, spmc, mpmc, mpsc

+много

Я так понимаю локер и cond используете для решения проблемы доступа к одному каналу с разных горутин. Т.е. две функции читают с одного канала данные, но надо чтобы они это делали по очереди. Т.е. первая выбрала 5 и только после этого вторая должна приступать к выборке из канала

Или я не правильно понял, когда это использовать

неправильно

Нет

локер - это такой мьютекс, на котором встают на паузу горутины, и потом можно их все разом отпустить

Простой кейс можно? Когда это надо

Это же примерно как поставить на паузу чтением с канала. Пока данных нет, рутина ждёт

я, честно сказать, затрудняюсь придумать реальную ситуацию, в котрой это было бы нужно

разве что, действительно, бродкаст сообщений для пула горутин

паб-саб можно замутить, наверное, только придумать, как удалять сообщения, которые уже всеми обработаны

но пабсаб мне будет проще сделать на каналах - по каналу на консьюмера, и пропихивать в каждый

Имхо, использовать канал с мьютексом - прямой путь к дедлоку.

ты меня извини, но то, как у нас мутексы сделаны - прямой путь к дедлоку

У вас 1 писатель и толпа читателей. И сообщение от писателя надо доставить всем читателям