Ограничения в C ++ 0x, гарантии только на атомные компоненты или память в целом

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

Например, в разделе 29.8 Заборы говорится следующее:

A ограничитель освобождения A синхронизируется с приобрести забор B, если существует атомный операции X и Y, оба работают на некоторый атомный объект M, такой что A последовательность перед X, X модифицирует M, Y является последовательность перед B, и Y читает значение, записанное X, или записанное значение каким бы то ни было побочным эффектом в гипотетическом выпускать последовательность X, если бы она были операцией освобождения.

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

Итак, являются ли ограждения / заграждения в правильных ограждениях C ++ 0x и формулировка просто невероятно плохой, или они чрезвычайно ограничены / бесполезны, как описано?

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

Thread A:
b = 9;
store_fence();
a = 5;

Thread B:
if( a == 5 )
{
  load_fence();
  c = b;
}

Предположим, a, b, c имеют размер, позволяющий иметь атомарную копию на платформе. Вышеупомянутое означает, что c когда-либо будет назначено только 9 . Обратите внимание, нас не волнует, когда поток B видит a == 5 , просто когда он это делает, он также видит b == 9 .

Какой код в C + + 0x, который гарантирует такие же отношения?

ОТВЕТ : Если вы прочитаете выбранный мной ответ и все комментарии, вы поймете суть ситуации. C ++ 0x, похоже, заставляет вас использовать атомар с забором, тогда как нормальный забор оборудования не имеет этого требования. Во многих случаях это все еще можно использовать для замены параллельных алгоритмов, если sizeof (atomic ) == sizeof (T) и atomic .is_lock_free () == true .

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