Является ли это правило об использовании volatile строгим?

Я не могу говорить о фактическом сценарии асинхронного доступа, так как я не очень хорошо разбираюсь в многопоточности, но модификатор volatile сообщает компилятору:

«Слушай, это может измениться в любое время, так что не кэшируй это, не помещай в реестр и не делай ничего подобного, ладно?»

Он не защищает от асинхронной записи, он просто отключает оптимизации, которые недействительны, если переменная может быть изменена внешними силами.

Изменить: в качестве потенциального примера, который не включает многопоточность (но включает исключительно запутанный код;), вот случай, когда важна изменчивость:

volatile bool keepRunning = true;
void Stuff() {
    int notAPointer = 0;

    notAPointer = (int)(&keepRunning); //Don't do this! Especially on 64-bit processors!

    while(keepRunning) {
        *(bool*)(notAPointer) = false;
    }

    printf("The loop terminated!");
}

Без этого модификатора volatile компилятор может сказать: «Эй, keepRunning никогда не модифицируется, так что мне даже не нужно генерировать код, который его проверяет!», хотя на самом деле мы просто модифицируем его тайно.

(На самом деле это, вероятно, все еще будет работать на неоптимизированной сборке. И это также может работать, если компилятор умен и замечает берущийся указатель. Но принцип тот же)

Прочтите это. Volatile не имеет ничего общего с многопоточностью.

Чтобы продолжить ответ Майка, это полезно в таких случаях (глобальные переменные, используемые, чтобы избежать сложности для этого примера):

static volatile bool thread_running = true;

static void thread_body() {
    while (thread_running) {
        // ...
    }
}

static void abort_thread() {
    thread_running = false;
}

В зависимости от того, насколько сложным является thread_body, компилятор может кэшировать значение thread_running в регистре, когда поток начинает работать, что означает, что он никогда не заметит, если значение изменится на false. volatile заставляет компилятор выдавать код, который будет проверять фактическую переменную thread_running в каждом цикле.

Я бы предложил значительно более строгое, но очень полезное правило: если вы не понимаете, что именно делает volatile, не используйте его. Вместо этого используйте lock. Если вы точно не понимаете, что делает lock и как его использовать, не используйте многопоточность.

Я бы сказал, что теоретически эти правила абсолютно верны, и volatile нужен каждый раз, когда к переменной обращаются 2 потока. (Даже при использовании мьютексов, поскольку они не препятствуют оптимизации компилятора.) Но на практике компиляторы достаточно хорошо распознают ситуации, когда переменная может быть изменена вне конкретной функции, поэтому ее значение не должно кэшироваться в регистрах. В большинстве случаев volatile не требуется.

Однажды я провел некоторое тестирование в MSVC, проверив вывод ассемблера для различных ситуаций, и все, что требовалось для предотвращения кэширования переменной, — это заставить другую функцию писать в ту же переменную или получать ее адрес. Глобальные переменные никогда не оптимизировались, если только не была включена «оптимизация всей программы» (поэтому компилятор может быть уверен, что переменная не изменена в других единицах трансляции).

Точно так же стандарт C++ не указывает, как должна работать volatile, вы должны смотреть, что конкретный компилятор делает для конкретной платформы. Кроме того, volatile немного неуловима, и то, что она делает, зависит от компилятора и модели памяти целевой платформы. Замки более интуитивно понятны в использовании.

Прежде чем вы слишком серьезно отнесетесь к статье, на которую вы ссылаетесь, вы можете прочитать еще одну. В более поздней публикации на Usenet, Андрей позже признал, что некоторые части оригинальной статьи были просто неверными, и указал на эту, как на более реалистичный взгляд на вещи (хотя обратите внимание, что ссылка, которую он дает на нее, похоже, устарела) .