Вводит ли ключевое слово volatile в C ++ забор памяти?

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

Насколько я понимаю, последовательность операций с изменчивыми объектами не может быть переупорядочена и должна быть сохранена. Похоже, это подразумевает, что некоторые ограждения памяти необходимы и что на самом деле нет способа обойти это. Правильно ли я говорю?

Есть интересное обсуждение этого связанного вопроса

Джонатан Уэйкли пишет :

... Доступ к различным изменчивым переменным не может быть переупорядочен компилятором, если они встречаются в отдельных полных выражениях ... верно, что volatile бесполезен для безопасности потоков, но не по причинам, которые он приводит. Это не потому, что компилятор может изменить порядок доступа к изменчивым объектам, а потому, что ЦП может их изменить. Атомарные операции и барьеры памяти не позволяют компилятору и процессору переупорядочивать

На что Дэвид Шварц отвечает в комментариях :

... С точки зрения стандарта C ++, нет никакой разницы между компилятором, который что-то делает, и компилятором, выдающим инструкции, которые заставляют оборудование что-то делать. Если ЦП может изменить порядок доступа к летучим объектам, то стандарт не требует сохранения их порядка. ...

... Стандарт C ++ не делает различий в том, что происходит при переупорядочивании. И вы не можете утверждать, что ЦП может изменить их порядок без видимого эффекта, так что это нормально - стандарт C ++ определяет их порядок как наблюдаемый. Компилятор соответствует стандарту C ++ на платформе, если он генерирует код, который заставляет платформу выполнять то, что требует стандарт. Если стандарт требует, чтобы доступ к летучим веществам не переупорядочивался, то платформа, которая переупорядочивает их, не соответствует требованиям. ...

Я хочу сказать, что если стандарт C ++ запрещает компилятору переупорядочивать доступы к отдельным переменным, исходя из теории, что порядок таких обращений является частью наблюдаемого поведения программы, то он также требует, чтобы компилятор испустил код, который запрещает процессору выполнять так. Стандарт не делает различий между тем, что делает компилятор, и тем, что код генерации компилятора заставляет делать ЦП.

Возникает два вопроса: «Правильно» ли кто-то из них? Что на самом деле делают реальные реализации?

Вместо того, чтобы объяснять, что volatileделает, позвольте мне объяснить, когда вам следует использовать volatile.

• Когда внутри обработчика сигнала. Поскольку запись в volatileпеременную - это практически единственное, что стандарт позволяет вам делать из обработчика сигналов. Начиная с C ++ 11, вы можете использовать std::atomicдля этой цели, но только если атомар не заблокирован.
• При работе с setjmp Intel .
• Когда вы имеете дело непосредственно с оборудованием, и вы хотите убедиться, что компилятор не оптимизирует ваши чтения или записи.

Например:

volatile int *foo = some_memory_mapped_device;
while (*foo)
    ; // wait until *foo turns false

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

Обратите внимание, что volatile это не имеет ничего общего с потоками. Приведенный выше пример не работает, если другой поток записывал в*foo потому что не задействована операция получения.

Во всех других случаях использование volatileдолжно рассматриваться как непереносимое и больше не проходить проверку кода, за исключением случаев, когда речь идет о компиляторах до C ++ 11 и расширениях компилятора (таких как /volatile:msпереключатель msvc , который включен по умолчанию в X86 / I64).

Вводит ли ключевое слово volatile в C ++ забор памяти?

Компилятор C ++, соответствующий спецификации, не обязан вводить ограждение памяти. Ваш конкретный компилятор может; направьте свой вопрос авторам вашего компилятора.

Функция "volatile" в C ++ не имеет ничего общего с потоками. Помните, что цель «volatile» - отключить оптимизацию компилятора, чтобы чтение из регистра, которое изменяется из-за внешних условий, не оптимизировалось. Является ли адрес памяти, в который записывается другой поток на другом процессоре, регистром, который изменяется из-за внешних условий? Нет. Опять же, если некоторые авторы компиляторов решили рассматривать адреса памяти, в которые записываются разные потоки на разных процессорах, как если бы регистры менялись из-за внешних условий, это их дело; они не обязаны этого делать. Они также не требуются - даже если это вводит ограждение памяти - например, для обеспечения каждого поток видит согласованный упорядочивания энергозависимых операций чтения и записи.

Фактически, volatile практически бесполезен для многопоточности в C / C ++. Лучше всего избегать этого.

Более того: ограждения памяти - это деталь реализации конкретных архитектур процессоров. В C #, где летучий явно будет предназначен для многопоточного, спецификация не говорит , что половина изгороди будет введена, так как программа может быть запущена на архитектуре , которая не имеет ограждений в первую очередь. Скорее, опять же, спецификация дает определенные (крайне слабые) гарантии того, какие оптимизации будут избегать компилятор, среда выполнения и ЦП, чтобы наложить определенные (чрезвычайно слабые) ограничения на порядок упорядочивания некоторых побочных эффектов. На практике эти оптимизации устраняются за счет использования полузаборов, но это деталь реализации, которая может измениться в будущем.

Тот факт, что вы заботитесь о семантике volatile на любом языке, поскольку они относятся к многопоточности, указывает на то, что вы думаете о совместном использовании памяти между потоками. Подумайте, просто не делайте этого. Это значительно усложняет понимание вашей программы и увеличивает вероятность того, что она будет содержать малозаметные ошибки, которые невозможно воспроизвести.

Дэвид упускает из виду тот факт, что стандарт C ++ определяет поведение нескольких потоков, взаимодействующих только в определенных ситуациях, а все остальное приводит к неопределенному поведению. Состояние гонки, включающее хотя бы одну запись, не определено, если вы не используете атомарные переменные.

Следовательно, компилятор имеет полное право отказаться от любых инструкций по синхронизации, поскольку ваш ЦП заметит разницу только в программе, которая демонстрирует неопределенное поведение из-за отсутствия синхронизации.

Прежде всего, стандарты C ++ не гарантируют барьеров памяти, необходимых для правильного упорядочивания операций чтения / записи, которые не являются атомарными. Переменные volatile рекомендуется использовать с MMIO, обработкой сигналов и т. д. В большинстве реализаций volatile бесполезно для многопоточности и обычно не рекомендуется.

Что касается реализации изменчивого доступа, это выбор компилятора.

Эта статья , описывающая поведение gcc, показывает, что вы не можете использовать изменчивый объект в качестве барьера памяти для упорядочивания последовательности записи в энергозависимую память.

Что касается поведения icc, я обнаружил, что этот источник также сообщает, что volatile не гарантирует упорядоченного доступа к памяти.

У компилятора Microsoft VS2013 другое поведение. В этой документации объясняется, как volatile обеспечивает семантику Release / Acquire и позволяет использовать изменчивые объекты в блокировках / выпусках в многопоточных приложениях.

Еще один аспект, который необходимо принять во внимание, заключается в том, что один и тот же компилятор может вести себя по- разному. в изменчивую в зависимости от целевой аппаратной архитектуры . В этом сообщении о компиляторе MSVS 2013 четко изложены особенности компиляции с volatile для платформ ARM.

Итак, мой ответ:

Вводит ли ключевое слово volatile в C ++ забор памяти?

будет: Не гарантируется, возможно, нет, но некоторые компиляторы могут это сделать. Не стоит полагаться на то, что это так.

Насколько мне известно, компилятор только вставляет ограждение памяти в архитектуру Itanium.

volatileКлючевое слово действительно лучше всего использовать для асинхронных изменений, например, обработчиков сигналов и отображенных в памяти регистров; обычно это неподходящий инструмент для многопоточного программирования.

Это зависит от того, какой компилятор «компилятор». Visual C ++ делает это с 2005 года. Но Стандарт не требует этого, поэтому некоторые другие компиляторы этого не требуют.

Это в основном из памяти и основано на pre-C ++ 11, без потоков. Но, участвуя в обсуждениях в комитете, я могу сказать, что у комитета никогда не было намерения, чтобыvolatile можно было бы использовать для синхронизации между потоками. Microsoft предложила это, но предложение не получилось.

Ключевая спецификация volatileзаключается в том, что доступ к изменчивому объекту представляет собой «наблюдаемое поведение», как и ввод-вывод. Точно так же компилятор не может изменить порядок или удалить определенный ввод-вывод, он не может изменить порядок или удалить доступ к изменчивому объекту (или, точнее, доступ через выражение lvalue с изменчивым квалифицированным типом). Первоначальная цель volatile заключалась в том, чтобы поддерживать ввод-вывод с отображением памяти. Однако «проблема» в том, что это определяется реализацией, что составляет «изменчивый доступ». И многие компиляторы реализуют это так, как если бы определение было «выполнена инструкция, которая читает или записывает в память». Это законное, хотя и бесполезное определение, если это указано в реализации. (Мне еще не удалось найти фактическую спецификацию для любого компилятора.

Возможно (и это аргумент, который я принимаю), это нарушает намерение стандарта, поскольку, если оборудование не распознает адреса как ввод-вывод с отображением памяти и не запрещает любое переупорядочение и т. Д., Вы даже не можете использовать volatile для ввода-вывода с отображением памяти, по крайней мере, на архитектурах Sparc или Intel. Тем не менее, ни один из компиляторов, на которые я смотрел (Sun CC, g ++ и MSC), не выводит никаких инструкций ограждения или мембраны. (Примерно в то время, когда Microsoft предлагала расширить правила volatile, я думаю, что некоторые из их компиляторов реализовали свое предложение и выдавали инструкции по ограничению для изменчивого доступа. Я не проверял, что делают последние компиляторы, но меня не удивит, если это зависит от на каком-то параметре компилятора. Версия, которую я проверял - я думаю, это была VS6.0 - однако, не создавала препятствий.)

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

Небольшое объяснение относительно барьеров памяти. Типичный ЦП имеет несколько уровней доступа к памяти. Есть конвейер памяти, несколько уровней кеша, затем ОЗУ и т. Д.

Инструкции по мембране промыть трубопровод. Они не меняют порядок, в котором выполняются операции чтения и записи, а просто заставляют невыполненные операции выполняться в данный момент. Это полезно для многопоточных программ, но не намного.

Кэш (ы) обычно автоматически согласовываются между процессорами. Если кто-то хочет убедиться, что кеш синхронизирован с ОЗУ, необходима очистка кеша. Это очень отличается от мембраны.

Компилятору необходимо volatileограничить доступ к памяти тогда и только тогда, когда это необходимо для использования volatileуказанных в стандартной работе ( setjmpобработчиков сигналов и т. Д.) На этой конкретной платформе.

Обратите внимание, что некоторые компиляторы действительно выходят за рамки того, что требуется стандартом C ++, чтобы сделать их volatileболее мощными или полезными на этих платформах. Переносимый код не volatileдолжен делать ничего сверх того, что указано в стандарте C ++.

Я всегда использую volatile в подпрограммах обслуживания прерываний, например, ISR (часто ассемблерный код) изменяет некоторую ячейку памяти, а код более высокого уровня, который выполняется вне контекста прерывания, обращается к ячейке памяти через указатель на volatile.

Я делаю это для ОЗУ, а также для ввода-вывода с отображением памяти.

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

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

Я думаю, что путаница с изменяемым порядком и переупорядочением инструкций проистекает из двух понятий переупорядочивания, которые делают процессоры:

1. Внеочередное исполнение.
2. Последовательность чтения / записи в память с точки зрения других процессоров (переупорядочение в том смысле, что каждый процессор может видеть другую последовательность).

Volatile влияет на то, как компилятор генерирует код, предполагая однопоточное выполнение (включая прерывания). Это ничего не говорит о командах барьера памяти, но скорее препятствует компилятору выполнять определенные виды оптимизации, связанные с доступом к памяти.
Типичный пример - это повторная выборка значения из памяти вместо использования одного, кэшированного в регистре.

Внеочередное исполнение

ЦП могут выполнять инструкции не по порядку / предположительно при условии, что конечный результат мог быть получен в исходном коде. ЦП могут выполнять преобразования, которые запрещены в компиляторах, поскольку компиляторы могут выполнять только те преобразования, которые являются правильными во всех обстоятельствах. Напротив, процессоры могут проверить правильность этих оптимизаций и отказаться от них, если они окажутся неверными.

Последовательность чтения / записи памяти с точки зрения других процессоров

Конечный результат последовательности инструкций, эффективный порядок, должен соответствовать семантике кода, созданного компилятором. Однако фактический порядок выполнения, выбранный ЦП, может быть другим. Эффективный порядок, видимый в других процессорах (каждый процессор может иметь разное представление), может быть ограничен барьерами памяти.
Я не уверен, насколько эффективный и фактический порядок может отличаться, потому что я не знаю, в какой степени барьеры памяти могут препятствовать выполнению процессорами вне очереди.

Источники:

• Барьеры памяти
• LLVM: Атомика
• ACCESS_ONCE () и ошибки компилятора

Пока я работал над загружаемым онлайн-видеоуроком по разработке 3D-графики и игрового движка, работая с современным OpenGL. Мы использовали volatileв одном из наших классов. Веб-сайт с учебным курсом можно найти здесь, а видео о работе с volatileключевым словом можно найти в Shader Engineсерии видео 98. Эти работы не являются моими собственными, но аккредитованы, Marek A. Krzeminski, MAScи это отрывок со страницы загрузки видео.

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

И если вы подписаны на его веб-сайт и имеете доступ к его видео в этом видео, он ссылается на эту статью, касающуюся использования Volatileс multithreadingпрограммированием.

Вот статья по ссылке выше: http://www.drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766

volatile: лучший друг многопоточного программиста

Текст: Андрей Александреску, 1 февраля 2001 г.

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

Не хочу портить вам настроение, но в этой колонке рассматривается ужасная тема многопоточного программирования. Если - как говорилось в предыдущем выпуске Generic - безопасное программирование исключений сложно, это детская игра по сравнению с многопоточным программированием.

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

Излишне говорить, что программисту, пишущему многопоточный код, нужна вся доступная помощь. Эта колонка посвящена условиям гонки - распространенному источнику проблем в многопоточных программах - и предоставляет вам идеи и инструменты, позволяющие их избежать, и, что довольно удивительно, заставить компилятор усердно работать, чтобы помочь вам в этом.

Просто небольшое ключевое слово

Хотя стандарты C и C ++ явно молчат, когда речь идет о потоках, они делают небольшую уступку многопоточности в виде ключевого слова volatile.

Как и его более известный аналог const, volatile является модификатором типа. Он предназначен для использования вместе с переменными, к которым осуществляется доступ и которые изменяются в разных потоках. По сути, без volatile либо написание многопоточных программ становится невозможным, либо компилятор тратит впустую огромные возможности оптимизации. Пояснения по порядку.

Рассмотрим следующий код:

class Gadget {
public:
    void Wait() {
        while (!flag_) {
            Sleep(1000); // sleeps for 1000 milliseconds
        }
    }
    void Wakeup() {
        flag_ = true;
    }
    ...
private:
    bool flag_;
};

Целью Gadget :: Wait, описанного выше, является проверка переменной-члена flag_ каждую секунду и возврат, когда эта переменная была установлена ​​в значение true другим потоком. По крайней мере, так задумал его программист, но, увы, Wait неверен.

Предположим, компилятор выясняет, что Sleep (1000) - это вызов внешней библиотеки, которая не может изменить переменную-член flag_. Затем компилятор заключает, что он может кэшировать flag_ в регистре и использовать этот регистр вместо доступа к более медленной встроенной памяти. Это отличная оптимизация для однопоточного кода, но в данном случае она вредит правильности: после вызова Wait для некоторого объекта Gadget, хотя другой поток вызывает Wakeup, Wait будет зацикливаться навсегда. Это связано с тем, что изменение flag_ не будет отражено в регистре, который кэширует flag_. Оптимизация слишком ... оптимистична.

Кэширование переменных в регистрах - очень ценная оптимизация, которая применяется большую часть времени, поэтому было бы жаль тратить ее зря. C и C ++ дают вам возможность явно отключить такое кеширование. Если вы используете модификатор volatile для переменной, компилятор не будет кэшировать эту переменную в регистрах - каждый доступ будет касаться фактического места в памяти этой переменной. Итак, все, что вам нужно сделать, чтобы комбинация Ожидание / Пробуждение Гаджета заработала, - это соответствующим образом квалифицировать flag_:

class Gadget {
public:
    ... as above ...
private:
    volatile bool flag_;
};

Большинство объяснений причин и использования volatile останавливаются здесь и советуют вам квалифицировать volatile-квалификацию примитивных типов, которые вы используете в нескольких потоках. Однако с volatile вы можете сделать гораздо больше, потому что это часть замечательной системы типов C ++.

Использование volatile с пользовательскими типами

Вы можете квалифицировать изменчивые не только примитивные типы, но и типы, определяемые пользователем. В этом случае volatile изменяет тип аналогично const. (Вы также можете одновременно применять const и volatile к одному и тому же типу.)

В отличие от const, volatile различает примитивные типы и типы, определяемые пользователем. А именно, в отличие от классов, примитивные типы по-прежнему поддерживают все свои операции (сложение, умножение, присваивание и т. Д.), Если они определены как изменчивые. Например, вы можете назначить энергонезависимое int для volatile int, но вы не можете назначить энергонезависимый объект изменчивому объекту.

Проиллюстрируем, как volatile работает с пользовательскими типами на примере.

class Gadget {
public:
    void Foo() volatile;
    void Bar();
    ...
private:
    String name_;
    int state_;
};
...
Gadget regularGadget;
volatile Gadget volatileGadget;

Если вы думаете, что volatile не так полезен с объектами, приготовьтесь к сюрпризу.

volatileGadget.Foo(); // ok, volatile fun called for
                  // volatile object
regularGadget.Foo();  // ok, volatile fun called for
                  // non-volatile object
volatileGadget.Bar(); // error! Non-volatile function called for
                  // volatile object!

Преобразование неквалифицированного типа в его изменчивый аналог тривиально. Однако, как и в случае с const, вы не можете вернуться из изменчивого состояния в неквалифицированное. Вы должны использовать гипс:

Gadget& ref = const_cast<Gadget&>(volatileGadget);
ref.Bar(); // ok

Квалифицированный volatile класс предоставляет доступ только к подмножеству своего интерфейса, подмножеству, которое находится под контролем разработчика класса. Пользователи могут получить полный доступ к интерфейсу этого типа только с помощью const_cast. Кроме того, как и постоянство, изменчивость распространяется от класса к его членам (например, volatileGadget.name_ и volatileGadget.state_ являются изменчивыми переменными).

изменчивые, критические секции и состояния гонки

Самым простым и наиболее часто используемым устройством синхронизации в многопоточных программах является мьютекс. Мьютекс предоставляет примитивы Acquire и Release. Как только вы вызываете Acquire в каком-либо потоке, любой другой поток, вызывающий Acquire, будет заблокирован. Позже, когда этот поток вызывает Release, будет освобожден ровно один поток, заблокированный при вызове Acquire. Другими словами, для данного мьютекса только один поток может получить процессорное время между вызовом Acquire и вызовом Release. Код, выполняемый между вызовом Acquire и вызовом Release, называется критическим разделом. (Терминология Windows немного сбивает с толку, потому что она называет сам мьютекс критическим разделом, тогда как «мьютекс» на самом деле является мьютексом между процессами. Было бы хорошо, если бы они назывались мьютексом потока и мьютексом процесса.)

Мьютексы используются для защиты данных от состояния гонки. По определению, состояние гонки возникает, когда влияние большего количества потоков на данные зависит от того, как потоки запланированы. Условия состязания возникают, когда два или более потока соревнуются за использование одних и тех же данных. Поскольку потоки могут прерывать друг друга в произвольные моменты времени, данные могут быть повреждены или неправильно интерпретированы. Следовательно, изменения и иногда доступ к данным должны быть тщательно защищены критическими секциями. В объектно-ориентированном программировании это обычно означает, что вы храните мьютекс в классе как переменную-член и используете его всякий раз, когда вы обращаетесь к состоянию этого класса.

Опытные многопоточные программисты, возможно, зевнули, читая два абзаца выше, но их цель - обеспечить интеллектуальную тренировку, потому что теперь мы будем связываться с изменчивым соединением. Мы делаем это, проводя параллель между миром типов C ++ и миром семантики потоковой передачи.

• За пределами критического раздела любой поток может в любой момент прервать работу любого другого; здесь нет контроля, поэтому переменные, доступные из нескольких потоков, изменчивы. Это соответствует первоначальной цели volatile - предотвращать непреднамеренное кэширование компилятором значений, используемых несколькими потоками одновременно.
• Внутри критической секции, определенной мьютексом, доступ имеет только один поток. Следовательно, внутри критического раздела исполняемый код имеет однопоточную семантику. Управляемая переменная больше не является изменчивой - вы можете удалить квалификатор volatile.

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

Вы входите в критическую секцию, блокируя мьютекс. Вы удаляете квалификатор volatile из типа, применяя const_cast. Если нам удастся объединить эти две операции, мы создадим связь между системой типов C ++ и семантикой потоковой передачи приложения. Мы можем заставить компилятор проверять условия гонки за нас.

LockingPtr

Нам нужен инструмент, который собирает захват мьютекса и const_cast. Давайте разработаем шаблон класса LockingPtr, который вы инициализируете с помощью изменчивого объекта obj и мьютекса mtx. В течение своего времени существования LockingPtr сохраняет полученные mtx. Кроме того, LockingPtr предлагает доступ к объекту obj. Доступ предоставляется в виде интеллектуального указателя через operator-> и operator *. Const_cast выполняется внутри LockingPtr. Приведение является семантически допустимым, поскольку LockingPtr сохраняет полученный мьютекс на протяжении всего его срока службы.

Сначала давайте определим скелет класса Mutex, с которым будет работать LockingPtr:

class Mutex {
public:
    void Acquire();
    void Release();
    ...    
};

Чтобы использовать LockingPtr, вы реализуете Mutex, используя собственные структуры данных и примитивные функции вашей операционной системы.

В шаблоне LockingPtr указан тип контролируемой переменной. Например, если вы хотите управлять Widget, вы используете LockingPtr, который вы инициализируете переменной типа volatile Widget.

Определение LockingPtr очень простое. LockingPtr реализует простой интеллектуальный указатель. Он ориентирован исключительно на сбор const_cast и критического раздела.

template <typename T>
class LockingPtr {
public:
    // Constructors/destructors
    LockingPtr(volatile T& obj, Mutex& mtx)
      : pObj_(const_cast<T*>(&obj)), pMtx_(&mtx) {    
        mtx.Lock();    
    }
    ~LockingPtr() {    
        pMtx_->Unlock();    
    }
    // Pointer behavior
    T& operator*() {    
        return *pObj_;    
    }
    T* operator->() {   
        return pObj_;   
    }
private:
    T* pObj_;
    Mutex* pMtx_;
    LockingPtr(const LockingPtr&);
    LockingPtr& operator=(const LockingPtr&);
};

Несмотря на свою простоту, LockingPtr является очень полезным помощником в написании правильного многопоточного кода. Вы должны определить объекты, которые совместно используются потоками как изменчивые, и никогда не использовать с ними const_cast - всегда используйте автоматические объекты LockingPtr. Проиллюстрируем это на примере.

Скажем, у вас есть два потока, которые совместно используют векторный объект:

class SyncBuf {
public:
    void Thread1();
    void Thread2();
private:
    typedef vector<char> BufT;
    volatile BufT buffer_;
    Mutex mtx_; // controls access to buffer_
};

Внутри функции потока вы просто используете LockingPtr для получения контролируемого доступа к переменной-члену buffer_:

void SyncBuf::Thread1() {
    LockingPtr<BufT> lpBuf(buffer_, mtx_);
    BufT::iterator i = lpBuf->begin();
    for (; i != lpBuf->end(); ++i) {
        ... use *i ...
    }
}

Код очень легко написать и понять - всякий раз, когда вам нужно использовать buffer_, вы должны создать LockingPtr, указывающий на него. Как только вы это сделаете, у вас будет доступ ко всему интерфейсу вектора.

Приятно то, что если вы допустите ошибку, компилятор укажет на нее:

void SyncBuf::Thread2() {
    // Error! Cannot access 'begin' for a volatile object
    BufT::iterator i = buffer_.begin();
    // Error! Cannot access 'end' for a volatile object
    for ( ; i != lpBuf->end(); ++i ) {
        ... use *i ...
    }
}

Вы не можете получить доступ к какой-либо функции buffer_, пока не примените const_cast или не используете LockingPtr. Разница в том, что LockingPtr предлагает упорядоченный способ применения const_cast к изменчивым переменным.

LockingPtr замечательно выразителен. Если вам нужно вызвать только одну функцию, вы можете создать безымянный временный объект LockingPtr и использовать его напрямую:

unsigned int SyncBuf::Size() {
return LockingPtr<BufT>(buffer_, mtx_)->size();
}

Вернуться к примитивным типам

Мы увидели, как хорошо volatile защищает объекты от неконтролируемого доступа и как LockingPtr обеспечивает простой и эффективный способ написания поточно-ориентированного кода. Теперь вернемся к примитивным типам, которые по-разному обрабатываются volatile.

Рассмотрим пример, в котором несколько потоков совместно используют переменную типа int.

class Counter {
public:
    ...
    void Increment() { ++ctr_; }
    void Decrement() { —ctr_; }
private:
    int ctr_;
};

Если Increment и Decrement должны вызываться из разных потоков, то в приведенном выше фрагменте есть ошибки. Во-первых, ctr_ должен быть изменчивым. Во-вторых, даже кажущаяся атомарной операция, такая как ++ ctr_, на самом деле является трехэтапной. Сама память не имеет арифметических возможностей. При увеличении переменной процессор:

• Читает эту переменную в регистре
• Увеличивает значение в регистре
• Записывает результат обратно в память

Эта трехэтапная операция называется RMW (чтение-изменение-запись). Во время части Modify операции RMW большинство процессоров освобождают шину памяти, чтобы предоставить другим процессорам доступ к памяти.

Если в это время другой процессор выполняет операцию RMW с той же переменной, мы имеем состояние гонки: вторая запись перезаписывает эффект первой.

Чтобы избежать этого, вы можете снова положиться на LockingPtr:

class Counter {
public:
    ...
    void Increment() { ++*LockingPtr<int>(ctr_, mtx_); }
    void Decrement() { —*LockingPtr<int>(ctr_, mtx_); }
private:
    volatile int ctr_;
    Mutex mtx_;
};

Теперь код правильный, но его качество хуже, чем у кода SyncBuf. Почему? Потому что с Counter компилятор не предупредит вас, если вы по ошибке получите прямой доступ к ctr_ (без его блокировки). Компилятор компилирует ++ ctr_, если ctr_ является изменчивым, хотя сгенерированный код просто неверен. Компилятор больше не ваш союзник, и только ваше внимание может помочь вам избежать состояния гонки.

Что тогда делать? Просто инкапсулируйте примитивные данные, которые вы используете в структурах более высокого уровня, и используйте volatile с этими структурами. Парадоксально, но хуже использовать volatile напрямую со встроенными модулями, несмотря на то, что изначально это было намерением использования volatile!

volatile функции-члены

До сих пор у нас были классы, которые собирают изменчивые элементы данных; Теперь давайте подумаем о разработке классов, которые, в свою очередь, станут частью более крупных объектов и будут совместно использоваться потоками. Здесь могут быть очень полезны изменчивые функции-члены.

При разработке класса вы определяете volatile только те функции-члены, которые являются потокобезопасными. Вы должны предположить, что код извне будет вызывать изменчивые функции из любого кода в любое время. Не забывайте: volatile означает бесплатный многопоточный код и отсутствие критического раздела; энергонезависимая - это однопоточный сценарий или внутри критической секции.

Например, вы определяете класс Widget, который реализует операцию в двух вариантах - поточно-ориентированном и быстром, незащищенном.

class Widget {
public:
    void Operation() volatile;
    void Operation();
    ...
private:
    Mutex mtx_;
};

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

При реализации изменчивой функции-члена первой операцией обычно является блокировка ее с помощью LockingPtr. Затем работа выполняется с использованием энергонезависимого родственника:

void Widget::Operation() volatile {
    LockingPtr<Widget> lpThis(*this, mtx_);
    lpThis->Operation(); // invokes the non-volatile function
}

Резюме

При написании многопоточных программ вы можете использовать volatile в своих интересах. Вы должны придерживаться следующих правил:

• Определите все общие объекты как изменчивые.
• Не используйте volatile напрямую с примитивными типами.
• При определении общих классов используйте изменчивые функции-члены для выражения безопасности потоков.

Если вы сделаете это и используете простой общий компонент LockingPtr, вы сможете написать поточно-ориентированный код и гораздо меньше беспокоиться об условиях гонки, потому что компилятор будет беспокоиться за вас и будет старательно указывать на те места, где вы ошибаетесь.

В паре проектов, в которых я участвовал, очень эффективно используются volatile и LockingPtr. Код чистый и понятный. Я помню пару тупиковых ситуаций, но я предпочитаю тупиковые ситуации условиям гонки, потому что их намного легче отлаживать. Проблем, связанных с условиями гонки, практически не было. Но тогда мало ли.

Благодарности

Большое спасибо Джеймсу Канце и Сорину Джиану, которые помогли с проницательными идеями.

---

Андрей Александреску - менеджер по развитию компании RealNetworks Inc. (www.realnetworks.com) из Сиэтла, штат Вашингтон, и автор знаменитой книги «Современный дизайн на C ++». С ним можно связаться на сайте www.moderncppdesign.com. Андрей также является одним из ведущих преподавателей семинара по C ++ (www.gotw.ca/cpp_seminar).

Эта статья может быть немного устаревшей, но она дает хорошее представление об отличном использовании модификатора volatile с использованием многопоточного программирования, чтобы помочь сохранить асинхронность событий, в то время как компилятор проверяет условия гонки за нас. Это может не напрямую отвечать на исходный вопрос OP о создании ограждения памяти, но я решил опубликовать это как ответ для других как отличную ссылку на хорошее использование volatile при работе с многопоточными приложениями.

Ключевое слово по volatileсуществу означает, что чтение и запись объекта должны выполняться точно так, как написано программой, и никоим образом не оптимизироваться . Двоичный код должен соответствовать коду C или C ++: загрузка, где это читается, хранилище, где есть запись.

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

volatile int i;
i = 1;
int j = i; 
if (j == 1) // not assumed to be true

volatileможет быть самым важным инструментом в наборе инструментов «C - язык ассемблера высокого уровня» .

Достаточно ли объявления объекта volatile для обеспечения поведения кода, который имеет дело с асинхронными изменениями, зависит от платформы: разные ЦП обеспечивают разные уровни гарантированной синхронизации для обычных операций чтения и записи в память. Вероятно, вам не стоит пытаться писать такой низкоуровневый многопоточный код, если вы не являетесь экспертом в этой области.

Атомарные примитивы обеспечивают хорошее представление объектов более высокого уровня для многопоточности, что упрощает рассуждения о коде. Почти все программисты должны использовать атомарные примитивы или примитивы, которые обеспечивают взаимные исключения, такие как мьютексы, блокировки чтения-записи, семафоры или другие блокирующие примитивы.