共享SRAM必须显式配置为Non-Cacheable或手动维护Cache：ZYNQ双核中L1 D-Cache独立，若未禁用缓存或同步，会导致脏数据滞留与读取旧值；需通过MMU页表、链接脚本设UNCACHED属性，或配合Clean/Invalidate指令及DSB/ISB屏障确保一致性。
共享SRAM必须显式配置为Non-Cacheable或手动维护Cache
ZYNQ双核（Cortex-A9）中，两个CPU核心各自有独立的L1 D-Cache，共享L2 Cache。如果你把一块SRAM区域（比如OCM或AXI BRAM）直接映射为普通内存并让两个核同时读写，cache line 会按写回策略滞留脏数据，导致对方看到旧值——这不是竞态，是硬件行为。默认情况下，ARM启动后所有内存区域都走Cacheable路径，所以第一步不是写代码，而是改MMU页表属性或链接脚本段属性。
常见错误现象：core0 写完一个标志位后触发中断，core1 在中断服务里读到的仍是0；或者DMA+CPU混用同一块SRAM时数据错乱。
- 最稳妥的做法：在链接脚本中将共享SRAM段（如
.shm）指定为UNCACHED属性，或通过MMU配置对应物理地址范围为Strongly-ordered/Device-nGnRnE（适用于不支持Cache的外设SRAM） - 若必须启用Cache（例如要高频访问大块图像数据），则必须配合
CleanDataCacheByAddr、InvalidateDataCacheByAddr和DSB指令组合，在每次跨核读写前后显式同步 - 注意对齐：所有Cache操作以32字节为单位，传入地址和长度必须按
32-byte aligned处理，否则部分平台会触发Data Abort
用__attribute__((section(".shm"), aligned(64)))强制缓存行对齐
即使你已确保内存区域不被Cache，多核并发访问结构体字段仍可能因伪共享（False Sharing）拖慢性能。比如两个核分别更新同一cache line里的不同字段，会导致该行在L1间反复失效与重载。
典型场景：一个共享状态结构体含 volatile uint32_t ready_flag 和 uint8_t payload[256]，若未对齐，ready_flag 和 payload[0] 很可能落在同一32字节行内。
- 使用
aligned(64)（推荐64字节，兼容L1/L2常见行宽）确保关键字段独占一行 - 结构体头部加
uint8_t padding[64]或用alignas(64)包裹整个结构体 - 避免在共享结构体内嵌动态数组；固定大小数组需确认总长是否跨越缓存行边界
- Windows/Linux用户容易忽略这点，但在ZYNQ裸机或FreeRTOS中，编译器不会自动帮你对齐共享段
DSB + ISB 是跨核同步的底线指令组合
仅靠原子操作（如 __atomic_store_n）不能解决Cache一致性问题。它只保证单核上的读写顺序和可见性，不触发其他核的Cache行失效。真正让修改“全局可见”，必须插入数据屏障（DSB）和指令屏障（ISB）。
错误写法：flag = 1; __atomic_thread_fence(__ATOMIC_SEQ_CST); —— 这在x86上可能够用，但在ARM Cortex-A9上缺了Cache同步语义。
- 写后通知对方：先
CleanDataCacheByAddr(ptr, size)（把脏数据写回内存），再DSB（确保Clean完成），再置标志位，最后DSB+ISB（让标志位更新对其他核立即可见） - 读后确认有效：先读标志位，若为真，则
InvalidateDataCacheByAddr(ptr, size)（丢弃本地旧副本），再DSB，再读真实数据 - 不要依赖编译器优化屏障（如
asm volatile("" ::: "memory")）替代硬件屏障；ARMv7必须用__dsb()/__isb()内建函数 - FreeRTOS中若使用
xTaskNotifyFromISR触发任务切换，屏障仍需手动加在通知前/后，通知机制本身不带Cache语义
Linux环境下优先用dma_alloc_coherent而非手动管理
如果你在ZYNQ上跑Linux（如PetaLinux），别自己手写Cache维护代码。内核已封装好整套一致性内存分配逻辑，dma_alloc_coherent 返回的内存天然满足：物理连续、Cache不可见（即写即达主存）、无需手动Clean/Invalidate。
常见误判：以为“用了Linux就不用管Cache了”。其实如果你绕过DMA API，直接 mmap 一段DDR给用户空间进程做共享，又没配 mem= 参数预留非Cacheable区域，那还是得自己处理一致性。
- 驱动侧分配：调用
dma_alloc_coherent(dev, size, &dma_handle, GFP_KERNEL)，得到虚拟地址用于CPU访问，dma_handle用于DMA控制器配置 - 用户空间映射：通过
ioctl将该物理地址透出，再用memmap=启动参数预留该段内存，或用/dev/mem+mmap（需root权限） - 切忌混用：
dma_alloc_coherent分配的内存不能传给dma_map_single，后者适用于可Cacheable内存，需配套维护 - 注意DMA方向：
DMA_TO_DEVICE/DMA_FROM_DEVICE/DMA_BIDIRECTIONAL必须匹配实际数据流向，否则Clean/Invalidate逻辑会反向
最易被忽略的一点：Cache一致性不是“开了就行”的开关，它是物理地址、MMU属性、屏障指令、总线协议四者咬合的结果。哪怕你正确调用了 Clean 和 Invalidate，如果那段内存本身被MMU标记为 Write-Through，或者AXI总线配置了 Cacheable 但从设备不支持snoop，照样失败。动手前务必查清你所用SRAM挂接的总线类型（OCM？AXI_HP？AXI_ACP？）及其Cache能力声明。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
