Есть ли неявный барьер памяти с отношениями synchronized-with в thread :: join?

У меня есть работающий код, который запускает несколько потоков, выполняющих некоторые операции, и если какой-либо из них терпит неудачу, они устанавливают для общей переменной значение false.

Затем основной поток присоединяется ко всем рабочим потокам. Моделирование этого выглядит примерно так (я закомментировал возможное исправление, но не знаю, нужно ли оно):

#include <thread>
#include <atomic>
#include <vector>
#include <iostream>
#include <cassert>

using namespace std;

//atomic_bool success = true;
bool success = true;

int main()
{
    vector<thread> v;
    for (int i = 0; i < 10; ++i)
    {
        v.emplace_back([=]
        {
            if (i == 5 || i == 6)
            {
                //success.store(false, memory_order_release);
                success = false;
            }
        });
    }
    for (auto& t : v)
        t.join();

    //assert(success.load(memory_order_acquire) == false);
    assert(success == false);

    cout << "Finished" << endl;
    cin.get();
    return 0;
}

Есть ли вероятность, что основной поток прочитает переменную успеха как true, даже если один из рабочих установил ее в false?

Я обнаружил, что thread :: join () - это полный барьер памяти (source), но подразумевает ли это отношение synchronized-with со следующим чтением успеха переменная из основного потока, чтобы гарантировать получение новейшего значения?

Является ли исправление, которое я опубликовал (в закомментированном коде), необходимым в этом случае (или, может быть, другое исправление, если оно неверно)?

Есть ли вероятность того, что чтение переменной success будет оптимизировано (поскольку она не является изменчивой), и мы получим старое значение независимо от предположительно существующего неявного барьера памяти на thread :: join?

Предполагается, что код работает на нескольких архитектурах (не могу запомнить их все, у меня нет файла makefile), но есть как минимум x86, amd64, itanium, arm7.

Спасибо за любую помощь с этим.

Изменить: я изменил пример, потому что в реальной ситуации несколько потоков могут попытаться записать в переменную success.