Увидят ли другие потоки запись в переменную размером с слово «volatile» в разумные сроки?

Знаете ли вы об архитектурах, в которых когерентности кэша недостаточно для обеспечения видимости между процессорами и ядрами?

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

Вики-статья о Intel QPI и о том, на каких процессорах он включен или отключен:

http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect

Если я напишу переменную в одном потоке, увидят ли это изменение другие потоки?

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

Каков порядок таймфрейма, в котором другие потоки увидят изменение?

Этого не может быть никогда. Нет никаких гарантий.

Знаете ли вы об архитектурах, в которых когерентности кэша недостаточно для обеспечения видимости между процессорами и ядрами?

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

Но если на этот вопрос можно ответить, то ответ - да. Опубликованные записи, предварительная выборка чтения и другие виды кэширования (например, то, что компиляторы делают с регистрами) существуют на реальных платформах.

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

Я могу ошибаться, но вам придется доказать, что я не прав.

Предполагая, что в настоящее время x86 / 64:

Если я напишу переменную в одном потоке, увидят ли это изменение другие потоки?

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

Каков порядок таймфрейма, в котором другие потоки увидят изменение?

Это действительно зависит от того, как вы измеряете. По сути, это будет время задержки памяти = 200 циклов на одном и том же узле NUMA. Примерно двойной на другом узле, на двухузловой коробке. Может отличаться на больших коробках. Если ваша запись будет переупорядочена относительно точки измерения времени, вы можете получить +/- 50 циклов.

Я измерил это несколько лет назад и получил 60-70 нс на приставках с частотой 3 ГГц и вдвое больше на другом узле.

Знаете ли вы об архитектурах, в которых когерентности кэша недостаточно для обеспечения видимости между процессорами и ядрами?

Я думаю, что смысл согласованности кеша - это наглядность. Сказав это, я не уверен, что машины риска Sun имеют такую ​​же когерентность кеша и расслабленную модель памяти, что и x86, поэтому я бы очень тщательно протестировал их. В частности, вам может потребоваться добавить барьеры освобождения памяти, чтобы принудительно сбросить записи в память.

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

Учитывая это, ваш второй вопрос (о сроках) не применим.

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

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

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

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

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

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