Модель памяти Заказ и видимость?

Я пытался искать детали по этому поводу, я даже читаю стандарт на мьютексах и атомке ... но все же я не мог понять гарантии видимости памяти C ++ 11. От того, что я понимаю, очень важная особенность мьютекса, кроме взаимного исключения, обеспечивает видимость. Ака недостаточно, чтобы только один нить за время увеличивается счетчик, важно, чтобы нить увеличила счетчик, который был сохранен по ветку, которая была последней с использованием Mutex (я действительно не знаю, почему люди не упоминают об этом больше при обсуждении Mutexes, может быть, у меня были плохие учителя :)). Итак, от того, что я могу сказать, атомной не обеспечивает немедленную видимость: (От человека, который поддерживает Boost :: Threade и реализовал битевую битую C ++ 11 и библиотеку Mutex):

Забор с Memory_Order_Seq_cst не применяет немедленный Видимость к другим потокам (и не делает инструкцию MFENGE). Ограничения памяти C ++ 0x - это просто --- ограничения. Memory_Order_Seq_cst Операции образуют общий заказ, но нет никаких ограничений на то, что такое порядок, за исключением того, что он должен быть согласованным по всем нитям, и он не должен нарушать другие заказа ограничения. В частности, потоки могут продолжать видеть «устаревшие» значения » в течение некоторого времени при условии, что они видят значения в порядке, соответствующем ограничения.

И я в порядке с этим. Но проблема в том, что у меня проблемы с пониманием того, что конструирует C ++ 11, касающиеся атомных, представляют собой «глобальные», и которые обеспечивают только согласованность на атомных переменных. В частности, у меня есть понимание, которое (если есть) из следующих заказов на память гарантируют, что забор памяти до и после нагрузки и магазинов: http://www.stdththread.co.uk/doc/headers/atomic/memory_order.html

Из того, что я могу сказать STD :: Memory_Order_seq_cst вставляет барьер Member, в то время как другие только принудительно заказывают операции на определенную память место расположения.

Итак, кто-нибудь может это очистить это, я предполагаю, что многие люди собираемся делать ужасные ошибки, используя STD :: Atomic, Esp, если они не используют по умолчанию (std :: memory_order_seq_cst Заказ на память)
2. Если я правильно, это означает, что вторая строка является Redundand в этом коде:

atomicVar.store(42);
std::atomic_thread_fence(std::memory_order_seq_cst);  

3. DO STD :: Atomic_Thrad_fence есть такие же требования, как mutexes в том смысле, что для обеспечения согласованности SEQ на неатомических варизах необходимо сделать STD :: Atomic_Truad_fence (std :: memory_order_seq_cst); перед загрузкой и std :: attomic_thread_fence (std :: memory_order_seq_cst);
После магазинов?
4.

  {
    regularSum+=atomicVar.load();
    regularVar1++;
    regularVar2++;
    }
    //...
    {
    regularVar1++;
    regularVar2++;
    atomicVar.store(74656);
  }

эквивалентно

std::mutex mtx;
{
   std::unique_lock ul(mtx);
   sum+=nowRegularVar;
   regularVar++;
   regularVar2++;
}
//..
{
   std::unique_lock ul(mtx);
    regularVar1++;
    regularVar2++;
    nowRegularVar=(74656);
}

, я думаю, нет, но я хотел бы быть уверенным.

Редактировать: 5 Может утверждать огонь?
Существуют только два потока.

atomic p=nullptr; 

Первая тема пишет

{
    nonatomic_p=(int*) malloc(16*1024*sizeof(int));
    for(int i=0;i<16*1024;++i)
    nonatomic_p[i]=42;
    p=nonatomic;
}

вторая нить чтения

{
    while (p==nullptr)
    {
    }
    assert(p[1234]==42);//1234-random idx in array
}