Как говорится в названии. В основном то, что мне интересно, это то, что атомный.StoreInt32 также блокирует операцию чтения во время написания?Golang: когда есть только один автор, измените значение с помощью atomic.StoreInt32, нужно ли использовать atom.LoadInt32 в нескольких чтениях?
Другой относительный вопрос :, atomic.StoreUint64(&procRate, procCount) эквивалент atomic.StoreUint64(&procRate, atomic.LoadUint64(&procCount))?
Заранее спасибо.
Да, вам нужно использовать атомные операции, когда вы загружаете и сохраняете одно и то же значение. Детектор гонки должен предупредить вас об этом.
Что касается второго вопроса, если одновременно используется значение procCount, то вам все равно необходимо загрузить его с помощью атомной операции. Эти два не эквивалентны:
atomic.StoreUint64(&procRate, procCount)
atomic.StoreUint64(&procRate, atomic.LoadUint64(&procCount))
Бывший читает procCount непосредственно перейти к StoreUint64, в то время как последний проходит копия благополучно получен с помощью LoadUint64.
Итак, ответ на первый вопрос заключается в том, что я должен использовать atomic.LoadInt, даже если есть только один поток для переменной, используя atomic.StoreInt? по второму вопросу первая строка прямо читает 'procCound', поэтому проблема в том, что значение, которое он читает, может быть средним статусом модификации, значение в это время может быть бессмысленным? – user2828102
Если есть параллельные чтения и записи _ любого типа_, вам необходимо сериализовать доступ с помощью мьютексов или атомных операций. Второй вопрос - это просто повторение первого, небезопасно читать 'procCount', если он изменяется, поэтому результат может быть бессмысленным. – JimB
Да, эти типы защищены как для чтения, так и для записи. –