Почему в учебнике написано что нету Data Race, хотя на самом деле есть?

Question

[danforth]

Всем привет!

Помогите навести порядок в голове по Go и concurrency. Читаю книгу Донована и Кернигана, где есть пример про параллельный неблокирующий кеш (часть 9.7).

На этой странице выделил желтым предложение, которое меня смущает: https://i.imgur.com/7XkoPh2.png
Они говорят, что мьютекс не является необходимым. Если открыть сам код, и предположить что мьютексов нету, на 34 строке мы получаем значение из хэш-таблицы. Далее, сравниваем его с nil и создаем новое значение entry, которое в итоге записываем обратно в хеш-таблицу. В это же время происходит чтение из хэш-таблицы другой goroutine, которая получает nil, и делает абсолютно то же самое что и предыдущая (в данном примере автор хотел сделать так, чтобы если одна гоурутина занимается вычислением тяжелой функции, другая не делала тоже самое, а ждала пока goroutine-основная закончил свою работу). Получается, что операция записи и чтения создают гонку данных. Race детектор говорит тоже самое.

Код: https://pastebin.com/LMmj3vGn

Comments

[Александр Павлюк]

Надо посмотреть, как это предложение написано в оригинале. Возможна ошибка перевода.

Answer 1

[ngreduce]

Учебник старый? В последних версиях Go, map очень любит паниковать при любой непонятной ситуации.
Возможно вместо мутекса и map иногда эффективнее будет https://golang.org/pkg/sync/#Map

Автор прав, состояния гонки после e := memo.cache[key] действительно нет. Но при одном большом но - GOMAXPROCS=1 (так было до go1.5), далее мы запросто можем получить concurrent read-write + panic или undefined behavior.

Concurrency очень сложная штука. Лучше всего эту проблему решили в Rust, но на нем больно писать.

Comments

[ngreduce]

А еще лучше пишите короткие функции и в них пишите так:
memo.mu.Lock()
defer memo.mu.Unlock()

Answer 2

[rustler2000]

Речь идет о том, что не надо защищать мутексом чтение значения entry.