Conversation
| fmt.Printf("validNumber=%d, invalidNumber=%d, unknownNumber=%d\n", | ||
| validNumber, invalidNumber, elementsNumber-validNumber-invalidNumber) | ||
| } | ||
| func main() { |
There was a problem hiding this comment.
Здесь и далее. Форматирование кода. Нет пробела между функциями.
|
|
||
| Метод `Add` должен быть вызван перед запуском горутин, а не внутри них! В противном случае мы не можем быть уверены, что вызвали его до метода `Wait`. | ||
|
|
||
| Следующий пример демонстрирует использование `sync.WaitGroup`. Программа должна обработать матрицу оборудования размером *1 млн.* элементов. Каждый элемент представляет собой структуру из имени оборудования и признака того, что оно валидно. Допустимым именем оборудования является любая строка, в которой отсутствуют символы `"!@#$%^&*()"`. В противном случае имя является недопустимым. Необходимо проставить признак допустимости имени для каждого элемента. |
There was a problem hiding this comment.
в которой отсутствуют символы
"!@#$%^&*()"
Когда хочешь получить валидную строку, то описываешь разрешенные символы, а не запрещенные. Например, разрешены alphanum и пробелы. А в твоем случае получается, что также разрешены непечатаемые символы, управляющие символы, бэктики, знак равно и тд и тп.
| @@ -0,0 +1,870 @@ | |||
| # Глава 19. Управление параллельным исполнением | |||
|
|
|||
| В этой главе мы познакомимся со счетчиком `sync.WaitGroup`. Он позволяет дождаться окончания работы нескольких горутин. До сих пор мы использовали для этого каналы. Счетчик `sync.WaitGroup` предоставляет более удобные и надежные средства для этих целей. | |||
There was a problem hiding this comment.
и надежные средства
из формулировки складывается впечатление, что каналы работают нестабильно) Ты же имел ввиду надежные в плане недопускания ошибок в коде? Лучше переформулируй
|
|
||
| Также отметим один важный момент. Функция `runtime.NumCPU` подсчитывает не только количество физических ядер, но и количество логических. Для некоторых задач нужно знать именно число физических ядер, потому что распараллеливать задачи по логическим не имеет смысла. Иногда это может даже замедлить работу. Например, для тяжелых математических расчетов, имеющих большое количество операций с плавающей точкой. | ||
|
|
||
| Такие задачи плохо запускать параллельно на ядрах, которые имеют только один блок для операций с плавающей точкой (FPU). Потоки запущенные, на одном ядре, будут конкурировать за FPU. |
There was a problem hiding this comment.
Потоки запущенные, на одном ядре, будут конкурировать за FPU.
Потоки, запущенные на одном ядре, будут конкурировать за FPU.
И предлагаю добавить ссылку:
| cpuNumber = 6 | ||
| ``` | ||
|
|
||
| Понятное дело, что вывод индивидуален, в зависимости от машины. |
There was a problem hiding this comment.
Я бы даже убрала эту фразу)
| } | ||
| ``` | ||
|
|
||
| ## Мьютекс чтения/записи `sync.RWMutex` |
There was a problem hiding this comment.
бэктики в заголовках не надо. Мы это плохо обрабатываем.
|
|
||
| ## Мьютекс чтения/записи `sync.RWMutex` | ||
|
|
||
| Мы говорили о мьютексах ранее. Как уже было сказано, мьютексы защищают данные, предотвращая состояние гонки. Примитив синхронизации `sync.Mutex` блокирует доступ к данным для всех других горутин, пока текущая горутина не завершит свою работу с этими данными. Однако это не всегда оптимально. Что, если `10` горутин одновременно читают данные? Если использовать `sync.Mutex`, то чтение окажется последовательным. В действительности эти `10` горутин не мешают друг другу. Может быть, тогда вообще обойтись без мьютекса? Это правильное решение в случае, когда никто эти данные не пишет. В случае, когда есть писатель, хотелось бы одновременно читать, но блокировать горутину на запись. Примитив `sync.RWMutex` решает эту задачу. |
There was a problem hiding this comment.
Мы говорили о мьютексах ранее.
Добавь плиз на тот абзац якорь и здесь сделай ссылку.
| * `RUnlock`. Снимает блокировку `Rlock`. | ||
|
|
||
|
|
||
| Примитив синхронизации `sync.RWMutex` оптимальнее, так как множественные чтения могут выполняться параллельно. Чтобы убедиться в этом, рассмотрим пример. В нем мы работаем с двумя кешами: `CacheRWMutex` и `CacheMutex`. Первый использует мьютекс `RWMutex`, второй — `Mutex`. Чем больше читателей и меньше писателей, тем больше выигрыш по производительности. |
There was a problem hiding this comment.
оптимальнее
лучше так не говорить, многие докапываются)
|
|
||
| ## Захват глобальных переменных горутиной | ||
|
|
||
| Существует одна известная проблема захвата глобальных переменных горутиной. Рассмотрим пример. На момент написания курса проблема все еще существовала. Для проверки этого кода использовался компилятор Go 1.26. Возможно, что на более новых версиях поведение будет изменено. |
There was a problem hiding this comment.
"одна" - лишнее слово
2 participants
No description provided.