能否用atomic_thread_fence使std::optional::has_value()无需额外atomic_bool即可线程安全？

我有一个std::optional<T>，由单个线程在完成计算、IO等操作后仅初始化一次。存在多个读取线程调用has_value()，若返回true则处理T的值。因为仅会被设置一次，我无需使用互斥锁，用一个std::atomic_bool就能实现同步，但这似乎有些冗余——毕竟std::optional本身就用一个额外的bool存储是否有值。重新实现optional并将内部bool设为原子类型又太粗糙。

以下是仅设置一次、永不重置的原子化optional简化示例：

template <typename T>
struct atomic_optional
{
    void set(T&& t)
    {
        opt = std::move(t);
        // 必须在设置值之后再设置isSet，确保与其他线程调用has_value()的顺序同步
        isSet = true;
    }

    // 调用get()前必须先调用此函数，否则违反契约
    bool has_value()
    {
        // 如果isSet不是原子的，无法保证所有线程都能看到opt.has_value()的变化
        return isSet;
    }

    // 仅当has_value()返回true时才能调用
    const T& get()
    {
        return *opt;
    }

    std::optional<T> opt {};
    std::atomic_bool isSet {false};
};

我能否用std::atomic_thread_fence替代std::atomic_bool？比如在设置值后用栅栏替代将isSet设为true，同时在has_value()中调用opt.has_value()前插入栅栏。cppreference提到可以围绕两个栅栏同步非原子操作，但也明确要求依赖原子对象（我这里没有）。如果栅栏可行，在两个栅栏上使用std::memory_order_seq_cst是否正确？尽管这在某些架构上会稍慢——获取和释放语义极为微妙，容易因代码变更失效，且难以复现（尤其是x86/x86-64上几乎不可能复现）。

以下是栅栏版本的代码——这样是否正确？有没有更适合的其他工具可用？

template <typename T>
struct atomic_optional
{
    void set(T&& t)
    {
        opt = std::move(t);
        std::atomic_thread_fence(std::memory_order_seq_cst); // 用memory_order_release是否更合适？
    }

    bool has_value()
    {
        std::atomic_thread_fence(std::memory_order_seq_cst); // 用memory_order_acquire是否更合适？
        return opt.has_value();
        // 如果返回false，值会立即过期，调用者需要理解这一点，比如执行一些操作后再次调用
    }

    const T& get()
    {
        return *opt;
    }

    std::optional<T> opt {};
};

¹这里的“冗余”是相对而言的——这个问题大多是学术性的。多数情况下，这种冗余可以忽略，因为std::optional添加的bool很可能需要填充字节，很多时候这个“额外的”std::atomic_bool可以放入这些填充字节中，不会实际增加对象大小。对于包含该成员且有其他1字节或2字节成员的复合对象，它可能节省一些字节，甚至避免对象需要填充。另外可以参考markable，它是std::optional的替代方案，不添加额外bool而是使用哨兵值。

内容的提问来源于stack exchange，提问作者user450775