Достаточно ли функций блокировки мьютекса без энергозависимости?

Если приведенный выше код правильный, как он неуязвим для проблем с кешированием?

До C ++ 0x это не так. И это не указано в C. Итак, это действительно зависит от компилятора. В общем, если компилятор не гарантирует, что он будет соблюдать ограничения порядка доступа к памяти для функций или операций, которые включают несколько потоков, вы не сможете писать многопоточный безопасный код с помощью этого компилятора. См. Потоки не могут быть реализованы как библиотеки Ганса Дж. Боэма.

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

(Что касается того, почему люди предложили volatile, некоторые компиляторы рассматривают volatile как барьер памяти для компилятора. Это определенно не стандартно.)

Самый простой ответ - volatile вообще не нужен для многопоточности.

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

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

Единственное, для чего volatile следует использовать в C ++, - это разрешить доступ к устройствам с отображением памяти, разрешить использование переменных между setjmp и longjmp и разрешить использование sig_atomic_t переменных в обработчиках сигналов. Само ключевое слово не делает переменную атомарной.

Хорошие новости: в C ++ 0x у нас будет STL-конструкция std::atomic, которую можно использовать для обеспечения атомарных операций и поточно-ориентированных конструкций для переменных. Пока ваш любимый компилятор не поддерживает это, вам может потребоваться обратиться к библиотеке boost или вырезать некоторый ассемблерный код, чтобы создать свои собственные объекты для предоставления атомарных переменных.

P.S. Большая путаница вызвана тем, что Java и .NET фактически применяют многопоточную семантику с помощью ключевого слова volatile. C ++, однако следует тому же примеру с C, где это не так.

Ваша библиотека потоковой передачи должна включать соответствующие барьеры ЦП и компилятора для блокировки и разблокировки мьютексов. Для GCC memory clobber в инструкции asm действует как барьер компилятора.

На самом деле, есть две вещи, которые защищают ваш код от кеширования (компилятора):

• Вы вызываете нечистую внешнюю функцию (pthread_mutex_*()), что означает, что компилятор не знает, что эта функция не изменяет ваши глобальные переменные, поэтому он должен их перезагрузить.
• Как я уже сказал, pthread_mutex_*() включает барьер компилятора, например: в glibc / x86 pthread_mutex_lock() заканчивается вызовом макроса _ 5_, в котором есть memory clobber, заставляющий компилятор перезагружать переменные.

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

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

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

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

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

Я предполагаю, что компилятор на самом деле не понимает, что pthread_mutex_lock () - это специальная функция, так что мы просто защищены точками последовательности?

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

Как это «особенное»? Он непрозрачен и рассматривается как таковой. Он не особенный среди непрозрачных функций.

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

Меня беспокоит кеширование. Может ли компилятор разместить копию _protected в стеке или в регистре и использовать это устаревшее значение в назначении?

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

Так что да, между вызовами непрозрачных функций. Не поперек.

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

Если нет, то что этому мешает? Уязвимы ли вариации этого паттерна?

Непрозрачность функций. Без встраивания. Код сборки. Системные вызовы. Сложность кода. Все, что заставляет компиляторы выходить из строя и думать, что «это сложная штука, просто обращается к ней».

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

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

• функция является «встроенной» (= доступна для встраивания) (либо включается глобальная оптимизация, либо все функции морально «встроены»);
• никакого барьера памяти не требуется (как в однопроцессорной системе с разделением времени, так и в многопроцессорной строго упорядоченной системе) в этом примитиве синхронизации (блокировка или разблокировка), поэтому он не содержит такой вещи;
• не используется никаких специальных инструкций (например, сравнения и установки) (например, для блокировки спина операция разблокировки представляет собой простую запись);
• отсутствует системный вызов для приостановки или пробуждения потоков (не требуется при блокировке вращения);

тогда у нас может возникнуть проблема, поскольку компилятор может оптимизировать вызов функции. Это тривиально устраняется путем вставки барьера компилятора, такого как пустой оператор asm с "clobber" для других доступных переменных. Это означает, что компилятор просто предполагает, что все, что может быть доступно для вызываемой функции, является " затертый ".

или должна ли защищенная переменная быть изменчивой.

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

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

• реальный ввод-вывод, такой как iostream
• системные вызовы
• другие нестабильные операции
• asm memory clobbers (но тогда побочный эффект памяти не переупорядочивается вокруг них)
• вызовы внешних функций (как они могли бы сделать одно из указанных выше)

Энергозависимость не упорядочена с учетом побочных эффектов энергонезависимой памяти. Это делает энергозависимую практически бесполезной (бесполезной для практического использования) для написания поточно-безопасного кода даже в самом конкретном случае, когда volatile может a priori помочь в том случае, когда не требуется никакого ограждения памяти: при программировании потоковых примитивов в системе разделения времени на одном процессоре. (Это может быть одним из наименее понятых аспектов C или C ++.)

Таким образом, в то время как volatile действительно предотвращает «кеширование», volatile даже не предотвращает переупорядочение операции блокировки / разблокировки компилятором, если все общие переменные не являются изменчивыми.

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

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

Пример: см. Пример одноэлементного шаблона
https://en.m.wikipedia.org/wiki/Singleton_pattern#Lazy_initialization

Почему кто-то пишет такой код? Ответ: Отсутствие накопления блокировки дает преимущество в производительности.

PS: Это мой первый пост о переполнении стека.

Нет, если объект, который вы блокируете, является изменчивым, например: если значение, которое он представляет, зависит от чего-то постороннего для программы (состояние оборудования). volatile НЕ следует использовать для обозначения какого-либо поведения, являющегося результатом выполнения программы. Если это действительно volatile, то я бы лично заблокировал значение указателя / адреса вместо базового объекта. например:

volatile int i = 0;
// ... Later in a thread
// ... Code that may not access anything without a lock
std::uintptr_t ptr_to_lock = &i;
some_lock(ptr_to_lock);
// use i
release_some_lock(ptr_to_lock);

Обратите внимание, что это работает, только если ВСЕ код, когда-либо использующий объект в потоке, блокирует один и тот же адрес. Так что помните об этом при использовании потоков с некоторой переменной, которая является частью API.