线程间共享uint32变量是否必须使用std::atomic？

1. 是否需要用std::atomic<>封装？ #

需要，哪怕你对读取时效性没有要求，也建议用std::atomic<uint32_t>封装这个变量。
C++标准明确规定，一个线程写共享变量、另一个线程不同步读取的场景属于数据竞争，是完全的未定义行为，和变量类型无关。哪怕uint32_t在你的目标架构上是单指令读写的，编译器的优化行为也不受控：比如编译器可能会把读线程的变量读取优化为寄存器缓存，导致永远读不到更新后的值；也可能把写线程的计数操作直接优化掉，完全不回写内存。
你可以给读写操作都指定memory_order_relaxed内存序，这种模式下原子操作仅保证操作的原子性和编译器不会乱序优化相关读写，不会引入任何内存屏障的开销，对UDP收包性能的影响可以忽略不计，完全符合你的使用需求。

2. 是否可以直接作为普通变量在线程间共享？ #

不可以。
即使你在X86等对齐后uint32_t读写天然原子的平台上，也绕不开刚才提到的编译器优化问题。如果你硬要用普通变量，需要手动加编译器屏障保证读写不会被优化掉，但这种实现是平台相关的，可移植性远不如直接用标准库提供的std::atomic，代码可读性也更差，完全没有必要省这一步。

3. 是否需要考虑缓存行大小之类的问题？ #

看你的UDP收包性能压力决定。
如果这个__counter变量和其他高频写入的变量存储在同一个缓存行里，会触发伪共享问题：其他变量的写入会导致该缓存行频繁失效，UDP线程写计数时需要重新从内存拉取缓存行，会额外消耗性能。如果你的收包压力不大，这点损耗基本感知不到；如果要做极致性能优化，可以给原子变量加alignas(64)对齐（64字节是绝大多数主流CPU的缓存行大小），保证这个变量单独占用一个缓存行，彻底避免伪共享。

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