é seguro ler um ponteiro para um atômico sem sincronização?

ponteiros são lidos ou escritos atomicamente em todas as arquiteturas.

Sim, em assembly. Mas você está escrevendo em C++, onde o que importa é o modelo de memória da linguagem e sua máquina abstrata. Seu código tem UB de corrida de dados de escrita+leitura simultâneas e não sincronizadas em g_atomic.

Na prática, o loop do leitor retirará a carga g_atomicdo seu loop. Como não é atômico, seria UB para outra thread alterá-lo, o que o compilador pode presumir que não acontece. Em outras palavras, criar corridas de dados em variáveis ​​não atômicas UB é o que permite que os compiladores continuem a fazer otimizações importantes para código single-threaded. (Eles não sabem quais globais são compartilhados ou não.)

Em C++, se você quiser o comportamento esperado, precisa solicitá-lo com std::atomic< T* >.
Com relaxedstore e load se não precisar de nenhuma ordenação.

Mas você realmente precisa ordenar para não publicar o ponteiro antes que o objeto apontado esteja totalmente construído. Você está usando um método lento thread_fence(seq_cst)para conseguir isso; na verdade, você só precisa de release, de preferência .store(val, release)em vez de uma cerca separada, para que ele possa ser compilado para AArch64 stlrem vez de uma instrução de barreira separada.

No seu caso, Té std::atomic<int>também conhecido como std::atomic_int. Então, seu código deve ser escrito assim para compilar no conjunto que você esperava obter do original. Renomeei g_atomicpara g_ptrporque ele e o apontador precisam ser atômicos.

( Na verdade, você não precisa que os objetos apontados sejam atômicos para que isso seja seguro. Então std::atomic< int* > g_ptr;, supondo que você não terá threads escrevendo esses objetos apontados. A inicialização acontece antes da leitura, graças à sincronização entre o escritor e o leitor. Não é verdade formalmente aqui, pois usei relaxedno leitor porque consumeestá obsoleto e isso compila para o conjunto correto na prática.)

#include <atomic>
using std::memory_order::relaxed, std::memory_order::release;
std::atomic<int> initval = 0;
std::atomic< std::atomic<int>* > g_ptr = &initval;

void writer()
{
    for (int i = 0; i < 101; i++)
    {
        auto* new_atomic = new std::atomic<int>{i};
        //std::atomic_thread_fence(std::memory_order_release);
        g_ptr.store(new_atomic, release);
    }
}

void reader()
{
    auto value = g_ptr.load(relaxed)->load(relaxed);
    while (value < 100)
    {
        //assert(value >= 0 && value <= 100);  // the loop condition already checks for <100, what's the point here?  Just the >= 0 part?
        auto tmp_ptr = g_ptr.load(relaxed);  // formally should be consume, but compilers strengthen it unnecessarily.
        value = tmp_ptr->load(relaxed);
        //value = g_ptr.load(relaxed)->load(relaxed);  // or without a tmp var
    }
}

( Godbolt )

o valor apontado é lido atomicamente

Sim, porque é std::atomic<int>.

tem que ser obtido da RAM

Bem, da memória compartilhada, então provavelmente do cache. O cache é coerente entre os núcleos pelos quais std::thread é executado, em todas as implementações C++ do mundo real. (Em placas com núcleos que compartilham memória, mas não têm coerência de cache, por exemplo, ARM DSP + microcontrolador, você não executa threads do mesmo programa nesses núcleos.)

Em C++, você precisa formalmente de pelo menos std::memory_order_consume, mas ele foi descontinuado e removido, pois a definição original era muito complicada de implementar. Os compiladores só o implementaram promovendo-o para acquire, sem realmente aproveitar a ordenação de dependências de memória que todas as ISAs, exceto DEC Alpha, oferecem.

Neste caso, não há uma maneira plausível para um compilador descobrir qual valor o ponteiro load deve ter produzido, então ele precisa criar um conjunto que carregue e desreferencia o ponteiro. Portanto, há uma dependência de dados entre o primeiro pointer.load(relaxed)e tmp->load(relaxed), e ISAs reais garantem que não pode haver reordenação de LoadLoad nesse caso. Na prática, funciona; o kernel Linux usa isso para RCU, por exemplo, para evitar quaisquer barreiras de memória em caminhos de leitura.

Veja C++11: a diferença entre memory_order_relaxed e memory_order_consume e respostas semelhantes sobre consumeordenação de dependências de memória.

Não, isso não é seguro. g_atomicDeveria ser std::atomic<std::atomic<int>*>. Um ponteiro atômico para um objeto atômico.

Mesmo que o hardware subjacente não interrompa leituras/gravações do tamanho de um ponteiro, já que seu ponteiro não é atômico nem volátil, o compilador está livre para otimizar todas as cargas/armazenamentos do valor do ponteiro, exceto a última gravação no último loop e a primeira carga no leitor.

Seu leitor provavelmente entrará em loop infinito, pois ele continua verificando o mesmo ponteiro alocado antigo em vez de pegar a próxima alocação.

Quanto ao valor armazenado no atomic<int>, a norma diz:

A inicialização não é uma operação atômica (6.9.2). [Nota: É possível ter acesso a um objeto atômico Adurante sua construção, por exemplo, comunicando o endereço do objeto recém-construído Aa outra thread por meio de memory_order::relaxedoperações em uma variável de ponteiro atômico adequada e, em seguida, acessando imediatamente Ana thread receptora. Isso resulta em comportamento indefinido. — nota final]

Portanto, o ponteiro atômico deve ser acessado com uma ordem de memória de aquisição/liberação. Sua cerca mais uma operação relaxada também deve funcionar (se combinada com uma cerca no lado do leitor), mas é mais cara do que o necessário.