4. 多核处理器并行计算：SMP与AMP模式选择、核间通信、负载均衡与锁优化

各位工程师，咱们今天聊点硬核的。多核处理器在机载平台上已经不是什么新鲜事了，但怎么用好它，说实话，坑不少。我见过太多项目，明明硬件算力堆得很高，实际跑起来却连单核的性能都发挥不出来。问题出在哪？多半是并行计算模式没选对，或者核间通信搞得太复杂。

这一章，我就把多核并行计算的核心问题掰开揉碎了讲。咱们从模式选择开始，再到通信机制，最后聊负载均衡和锁优化。嗯，都是实战中绕不开的坎。

4.1 SMP与AMP：两种截然不同的哲学

先问个问题：你手头的多核处理器，打算怎么用？是把所有核心看作一个统一的处理器池，还是给每个核心分配明确的任务？

这两种思路，对应着两种主流模式：SMP（对称多处理）和AMP（非对称多处理）。

特性	SMP	AMP
操作系统	单个OS管理所有核心	每个核心可运行独立OS或裸机程序
内存视图	统一共享内存空间	每个核心有私有内存区域
任务调度	OS自动负载均衡	开发者手动分配任务
实时性	受OS调度影响，抖动较大	可做到极低延迟、确定性强
开发难度	相对简单，但调试锁问题头疼	需要精细管理核间交互
典型场景	通用计算、数据并行处理	传感器融合、飞控、信号处理

SMP 的好处是开发快。你写一个多线程程序，操作系统帮你把线程分配到各个核心上。但问题也明显——锁竞争、缓存一致性开销，这些在机载这种高实时场景下，有时候是致命的。

AMP 则相反。每个核心跑自己的代码，互不干扰。我在一个飞控项目里就用的AMP模式：一个核心专门跑控制律，另一个核心跑导航解算，第三个核心做IO管理。每个核心的任务是固定的，延迟可控。但代价是，核间通信得自己搭。

4.2 核间通信：共享内存 vs 消息传递

模式选好了，接下来就是核心之间怎么说话。说白了，就两种方式：共享内存和消息传递。

4.2.1 共享内存

这是最直接的方式。多个核心访问同一块物理内存，通过读写共享变量来交换数据。速度快，延迟低，但问题也明显——数据一致性。

我举个例子。两个核心同时更新一个传感器数据缓冲区，如果没有同步机制，一个核心读到一半的数据可能被另一个核心覆盖了。这就是典型的竞态条件。

解决方案？用原子操作或者自旋锁。但注意，自旋锁在AMP模式下要特别小心。我曾经在一个项目里，核心A持有一个锁，核心B在等这个锁，结果核心A被高优先级任务抢占了，核心B就死等了。嗯，这就是优先级反转的一种变体。

// 共享内存示例：使用原子操作更新计数器
// 假设 g_counter 位于共享内存区域
void safe_increment(volatile uint32_t *counter) {
    // 使用硬件支持的原子加操作
    __sync_fetch_and_add(counter, 1);
}

// 或者用自旋锁保护临界区
void spinlock_lock(volatile uint32_t *lock) {
    while (__sync_lock_test_and_set(lock, 1)) {
        // 等待锁释放
        // 注意：这里可以插入一个CPU暂停指令减少功耗
        __asm__ __volatile__("pause" ::: "memory");
    }
}

4.2.2 消息传递

消息传递则是另一种思路。核心之间不直接共享内存，而是通过队列、邮箱或者硬件通道来发送消息。每个核心有自己的私有内存，消息的发送方把数据拷贝到接收方的缓冲区里。

这种方式天然避免了数据竞争，因为每个核心只操作自己的内存。但代价是拷贝开销。对于大数据块，消息传递的延迟会比共享内存高。

在机载平台上，我常用的是无锁环形缓冲区（Lock-Free Ring Buffer）。它结合了共享内存的速度和消息传递的安全性。

// 无锁环形缓冲区（单生产者-单消费者场景）
#define BUFFER_SIZE 256

typedef struct {
    volatile uint32_t head;  // 生产者写入位置
    volatile uint32_t tail;  // 消费者读取位置
    uint32_t data[BUFFER_SIZE];
} lockfree_ring_t;

// 生产者写入
bool ring_push(lockfree_ring_t *ring, uint32_t value) {
    uint32_t next_head = (ring->head + 1) % BUFFER_SIZE;
    if (next_head == ring->tail) {
        return false; // 缓冲区满
    }
    ring->data[ring->head] = value;
    // 使用内存屏障确保数据写入完成后再更新head
    __sync_synchronize();
    ring->head = next_head;
    return true;
}

// 消费者读取
bool ring_pop(lockfree_ring_t *ring, uint32_t *value) {
    if (ring->tail == ring->head) {
        return false; // 缓冲区空
    }
    *value = ring->data[ring->tail];
    __sync_synchronize();
    ring->tail = (ring->tail + 1) % BUFFER_SIZE;
    return true;
}

4.3 负载均衡：别让一个核心累死，其他核心闲死

多核系统最怕什么？负载不均。一个核心跑满100%，其他核心在喝茶。你想想看，这跟单核有什么区别？

在SMP模式下，操作系统会尽量把任务均匀分配到各个核心。但操作系统不知道你的任务特性。比如，一个任务频繁访问内存，另一个任务全是CPU计算，它们混在一起调度，效果可能很差。

我建议的做法是：手动绑定核心（CPU Affinity）。把计算密集型的任务绑定到某个核心，把IO密集型的任务绑定到另一个核心。这样能减少缓存切换带来的开销。

// Linux下绑定线程到指定核心
#include <sched.h>

void bind_to_core(int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);
    
    if (sched_setaffinity(0, sizeof(cpu_set_t), &cpuset) != 0) {
        // 处理错误
    }
}

在AMP模式下，负载均衡完全由你掌控。你需要根据每个核心的任务量，动态调整任务分配。比如，一个核心处理传感器数据，如果数据量突然增大，你可以把一部分处理逻辑迁移到空闲核心上。

但注意，任务迁移是有代价的。上下文切换、缓存失效、数据同步，这些开销可能抵消掉负载均衡带来的好处。所以，我的原则是：能不迁移就不迁移，非要迁移就批量迁移。

4.4 锁优化：能不用锁就不用，实在要用就快进快出

锁是并行编程的万恶之源。它会导致线程阻塞、优先级反转、死锁……但有时候你又不得不用。怎么办？

我总结了几条实战经验：

• 尽量用无锁数据结构。 比如前面提到的无锁环形缓冲区。原子操作比锁快一个数量级。
• 缩小临界区。 只在真正需要保护的那几行代码上加锁。千万别在锁里面做IO操作或者复杂计算。
• 使用读写锁。 如果读操作远多于写操作，读写锁能大幅提升并发性能。
• 避免嵌套锁。 一个线程持有一个锁，再去申请另一个锁，很容易死锁。我见过最离谱的案例，一个函数里嵌套了五层锁，最后谁也跑不动。

最后，我想说一句：多核并行计算，不是核心越多越快。选对模式、设计好通信、做好负载均衡、优化锁的使用，才能真正发挥多核的威力。嗯，这些经验，都是我在一次次调试到凌晨三点后总结出来的。