C89多线程开发如何实现无锁无volatile的等效C11原子操作

不存在纯C89标准下、不使用锁、不依赖volatile、兼容所有编译器与操作系统的原子操作实现。
C89标准从根上就没有定义多线程执行模型，既不承认多个执行流并发访问同一块内存的场景，也没有对内存操作的原子性、跨线程可见性、指令重排顺序做任何约束。你要求的能力根本不在C89标准的覆盖范围内，自然不可能靠纯标准C89的语法实现。

• C89的所有语言规则都是基于单线程执行假设设计的：只要代码的单线程执行语义不变，编译器可以任意重排内存操作、把频繁访问的变量永久缓存到寄存器、甚至直接删掉被判定为“无意义”的内存读写。如果不借助编译器扩展、锁或者你不想用的volatile，你连“线程A写的值能被线程B读到”这个最基础的保证都拿不到。
• 原子操作是强依赖硬件架构的能力：x86需要带LOCK前缀的指令，ARM需要LDREX/STREX独占访问指令，RISC-V需要AMO类指令，不同架构的实现完全不通用。C89没有提供任何语法或库函数抽象这层硬件能力，纯C89代码不可能生成对应平台的原子指令。
• 你追求的“写一次兼容所有平台、长期不用修改”的原子操作能力，恰恰是C11引入stdatomic.h要解决的核心问题。在C11标准化之前，所有原子操作实现都是平台/编译器相关的，不存在通用解。

如果不追求覆盖所有冷门、停止维护的编译器，只需要兼容当前仍在广泛使用的主流编译器（GCC 4.7+、Clang 3.2+、Intel C++ Compiler 13+、MSVC 2012+），可以直接用各编译器在C89模式下就支持的原子内建函数做一层薄封装，不需要切换到C11标准，也不需要手动加锁。
对应你给出的双线程操作bool变量的场景，实现代码如下：

/* C89兼容的无锁原子bool实现，适配主流编译器，无手动volatile修饰 */
#if defined(__GNUC__) || defined(__clang__) || defined(__INTEL_COMPILER)
typedef int c89_atomic_bool;
#define c89_atomic_bool_init 0
#define c89_atomic_store_bool(ptr, val) \
    __atomic_store_n((ptr), (val), __ATOMIC_RELEASE)
#define c89_atomic_load_bool(ptr) \
    __atomic_load_n((ptr), __ATOMIC_ACQUIRE)

#elif defined(_MSC_VER)
#include <windows.h>
typedef LONG c89_atomic_bool;
#define c89_atomic_bool_init 0
#define c89_atomic_store_bool(ptr, val) \
    InterlockedExchange((ptr), (val))
#define c89_atomic_load_bool(ptr) \
    InterlockedCompareExchange((ptr), 0, 0)

#else
#error "请为当前使用的编译器补充对应原子操作内建函数的适配"
#endif

static c89_atomic_bool theBool = c89_atomic_bool_init;

void funFromFirstThread()
{
    c89_atomic_store_bool(&theBool, 1);
}

void funFromSecondThread() /* 会被重复调用 */
{
    if (c89_atomic_load_bool(&theBool))
    {
        /* 执行业务逻辑 */
    }
}

这个实现的说明：

• 全程无锁，原子操作直接映射到对应硬件的原子指令，性能和C11的_Atomic实现一致
• GCC/Clang/ICC路径下完全不需要volatile修饰，内建函数会自动处理编译器重排限制、硬件内存屏障插入的逻辑，符合你不使用volatile的要求；MSVC路径下的类型定义虽然带volatile，但这是Win32 Interlocked API的强制要求，不是用来做跨线程可见性保证的hack写法
• 只要给新的编译器补上对应的内建函数适配，这套代码可以长期维护，不需要依赖高版本C标准

如果你真的需要做到100%兼容所有支持C89的编译器，包括完全不提供原子内建函数的老旧编译器，那你只能使用操作系统提供的互斥锁做同步，没有其他无锁方案可选。

额外说明：如果真的追求代码的长期可维护性，切换到C11使用标准stdatomic.h是成本最低的选择。目前C11已经发布十余年，所有仍在维护的C编译器都已支持标准原子操作库，反而自己维护跨编译器的原子兼容层需要长期跟进新架构、新编译器的适配，长期成本更高。

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