多核通信机制（上）：共享内存架构、核间中断（IPI）、原子操作与自旋锁
各位同学，今天我们来聊聊多核DSP里最核心、也最容易踩坑的部分——核间通信。
你想想看，一个芯片里塞了四核、八核甚至更多DSP核心，它们之间怎么交换数据？怎么同步任务？总不能各干各的，最后乱成一锅粥吧？
我做了十几年芯片架构，见过太多因为通信机制没设计好，导致性能瓶颈甚至功能异常的案例。今天这堂课，咱们就把共享内存、核间中断、原子操作和自旋锁这几个基础但关键的机制讲透。
核心观点：多核通信的本质，是解决“数据一致性”和“任务同步”两个问题。共享内存解决数据共享，IPI解决事件通知，原子操作和自旋锁解决资源互斥。
一、共享内存架构：最直接的通信方式
共享内存，说白了就是让多个核心都能访问同一块物理内存区域。这是多核通信最基础、最常用的方式。
我在项目中遇到过一种情况：两个DSP核同时往共享内存的同一个地址写数据，结果读出来的数据既不是A核写的，也不是B核写的，而是两者混合的“脏数据”。这就是典型的竞争条件（Race Condition）。
共享内存架构有几个关键设计点：
- 内存分区：通常把共享内存划分为多个区域，每个核心有专属的“信箱”区域，以及公共的数据缓冲区。
- 缓存一致性：如果每个核心有自己的L1/L2缓存，必须保证缓存与共享内存之间的一致性。否则，Core 0写了一个值，Core 1读到的却是缓存中的旧值。
- 访问仲裁：多个核心同时访问共享内存时，硬件需要做仲裁。我建议使用“轮询优先”或“固定优先级”策略，具体看你的应用场景。
个人经验：设计共享内存时，我习惯把关键数据结构（比如任务队列、状态标志）放在共享内存的固定地址，并且用“缓存行对齐”（Cache Line Alignment）来避免伪共享（False Sharing）问题。伪共享会让性能下降30%以上，别问我怎么知道的……
二、核间中断（IPI）：让核心之间“喊话”
共享内存解决了数据共享问题，但核心之间怎么知道对方有数据要处理？总不能一直轮询吧？太浪费功耗了。
核间中断（Inter-Processor Interrupt，IPI）就是干这个的。一个核心可以通过写特定寄存器，向另一个核心发送中断信号。
IPI的典型工作流程是这样的：
- Core 0 把数据写入共享内存的某个区域。
- Core 0 写IPI触发寄存器，向Core 1发送中断。
- Core 1 收到中断，进入中断服务程序（ISR），读取共享内存中的数据。
- Core 1 处理完数据后，写状态标志通知Core 0。
嗯，这里要注意：IPI中断服务程序要尽量短。我曾经见过一个项目，ISR里做了大量数据处理，结果导致其他核心的中断被长时间阻塞，系统响应延迟飙升。
避坑指南：我曾经在调试一个4核DSP系统时，发现IPI中断偶尔会丢失。查了三天，最后发现是中断优先级配置问题——低优先级的中断被高优先级中断淹没了。所以，IPI中断的优先级要合理设置，通常建议设为中等偏上。
三、原子操作：不可分割的“事务”
共享内存和IPI都准备好了，但还有一个问题：多个核心同时修改同一个变量怎么办？比如一个全局计数器，Core 0和Core 1同时执行“count++”，结果可能只加了1次。
为什么？因为“count++”在底层其实是三条指令：读count、加1、写回count。如果两个核心同时执行，就会发生“读-改-写”冲突。
原子操作就是解决这个问题的。它保证“读-改-写”这三步作为一个整体执行，中间不会被其他核心打断。
常见的原子操作包括：
- 原子加/减：比如atomic_add(&count, 1)，保证多核安全。
- 比较并交换（CAS）：比较内存中的值是否等于期望值，如果是则交换为新值。这是实现自旋锁的基础。
- 测试并设置（TAS）：读取一个标志位，同时把它设置为1。常用于实现简单的互斥锁。
我个人的习惯是：能用原子操作解决的问题，绝不用软件锁。原子操作在硬件层面实现，开销远小于软件锁。
四、自旋锁：轻量级的互斥机制
自旋锁（Spinlock）是最简单的锁机制。它的原理是：当一个核心想要访问共享资源时，先尝试获取锁。如果锁被其他核心持有，它就“自旋”——在一个循环里不断检查锁是否释放。
自旋锁的典型实现（基于CAS原子操作）：
// 自旋锁结构体
typedef struct {
volatile int locked; // 0: 未锁定, 1: 已锁定
} spinlock_t;
// 初始化锁
void spin_init(spinlock_t *lock) {
lock->locked = 0;
}
// 获取锁（自旋等待）
void spin_lock(spinlock_t *lock) {
while (atomic_cas(&lock->locked, 0, 1) != 0) {
// 自旋等待，可插入CPU暂停指令降低功耗
__asm__("nop");
}
}
// 释放锁
void spin_unlock(spinlock_t *lock) {
atomic_store(&lock->locked, 0);
}
自旋锁的优点是轻量、快速，适合锁持有时间很短的场景。但缺点也很明显：如果锁持有时间过长，其他核心会一直空转，浪费功耗。
关键原则：自旋锁只适合保护“微秒级”的临界区。如果临界区执行时间超过几十微秒，建议改用信号量或互斥锁，让等待的核心进入休眠状态。
我在项目中遇到过一个问题：一个核心持有自旋锁后，被高优先级中断打断，中断服务程序又去尝试获取同一个锁——死锁了！这就是所谓的“锁持有者被抢占”问题。解决方案是：在持有自旋锁期间，关闭本地中断。
嗯，这里再补充一个优化技巧：在自旋等待循环中插入“暂停”指令（如ARM的WFI、x86的PAUSE），可以降低功耗并提高其他核心获取锁的机会。我在低功耗DSP设计中经常用这个技巧。
五、四种机制的协同工作
在实际系统中，这四种机制通常是配合使用的：
| 场景 | 使用机制 | 说明 |
|---|---|---|
| Core 0 向 Core 1 发送任务 | 共享内存 + IPI | Core 0 把任务描述写入共享内存，然后发送IPI通知Core 1 |
| 多个核心更新全局计数器 | 原子操作 | 直接用atomic_add，不需要锁 |
| 多个核心访问共享队列 | 自旋锁 + 原子操作 | 用自旋锁保护队列的入队/出队操作，内部用原子操作维护队列指针 |
| 低功耗场景下的同步 | IPI + 信号量 | 等待核心进入休眠，由IPI唤醒，避免自旋浪费功耗 |
我的建议：在设计多核通信方案时，先画一张“数据流图”，标清楚哪些数据是共享的、哪些核心需要访问、访问频率如何。然后根据这些信息选择合适的通信机制。不要一上来就用自旋锁，有时候一个原子操作就能搞定。
好了，今天的内容就到这里。共享内存、IPI、原子操作和自旋锁，这四个机制是构建多核通信的基石。下一节课我们会继续深入，讲更高级的通信模式——比如消息队列和硬件加速器。