4. 多核调度核心概念：CPU亲和性（Affinity），任务在不同核心上的绑定，核间通信（IPC）简介

好，咱们进入多核调度的核心地带了。说实话，很多工程师从单核转到多核开发，第一个懵掉的概念就是——任务到底跑在哪个核上？

单核时代，你根本不用操心这个问题。一个CPU，所有任务排队跑。但到了多核，事情就变了。你想想看，如果两个核心都在抢同一个资源，或者一个高优先级任务被调度到了繁忙的核上，那性能反而会下降。

所以，这一章我们要聊三个关键点：CPU亲和性、任务绑定、以及核间通信（IPC）。我个人习惯把这三者称为“多核调度的三驾马车”。

4.1 CPU亲和性（Affinity）——让任务找到“对”的核

CPU亲和性，说白了就是把某个任务“粘”在某个或某几个核心上。为什么要这么做？

  • 减少缓存失效：任务一直在同一个核上跑，L1/L2缓存里的数据是热的。换核跑，缓存全得重刷，性能损失很大。
  • 避免资源竞争：比如两个任务都频繁访问同一个外设，把它们绑到同一个核上，可以减少核间同步的开销。
  • 满足实时性要求：高优先级的中断或任务，可以独占一个核心，保证响应时间。

我在项目中遇到过这样一个坑：一个音频处理任务，本来跑在Core0上，一切正常。后来系统升级，任务被调度到了Core1，结果音频出现断断续续的卡顿。查了半天，发现Core1上还跑着一个高频率的定时器中断，把音频任务的时间片挤碎了。嗯，这就是典型的“亲和性没设好”的案例。

4.1.1 如何设置CPU亲和性？

不同的RTOS，API不一样。但思路是相通的。我以FreeRTOS和Zephyr为例，给你看看代码长什么样。

FreeRTOS（使用任务通知或调度器钩子）

// 假设我们有一个任务句柄 xTaskAudio
// 在任务创建后，设置其亲和性为 Core0

void vApplicationSetupAffinity(void)
{
    // 获取当前任务句柄
    TaskHandle_t xTask = xTaskGetHandle("AudioTask");
    
    // 设置亲和性掩码：只允许在 Core0 上运行
    // 注意：FreeRTOS 原生不直接支持亲和性，需要借助 MPU 或调度器钩子
    // 这里展示的是概念性代码
    ulTaskSetAffinity(xTask, 0x01);  // 0x01 表示 Core0
}

Zephyr RTOS（使用线程属性）

// Zephyr 中，亲和性在创建线程时指定
#define STACK_SIZE 1024

K_THREAD_DEFINE(audio_tid, STACK_SIZE,
                audio_thread_entry, NULL, NULL, NULL,
                5, 0, K_FOREVER);

// 设置亲和性：绑定到 Core0
void main(void)
{
    // 启动前设置亲和性
    k_thread_cpu_mask_clear(audio_tid);
    k_thread_cpu_mask_enable(audio_tid, 0);  // 0 表示 Core0
    k_thread_start(audio_tid);
}
我的小建议： 不要一上来就把所有任务都绑死。先让系统自由调度跑一段时间，用性能分析工具看看各个核心的负载情况。然后再根据实际数据，把关键任务绑定到合适的核上。这叫“先测量，后绑定”。

4.2 任务在不同核心上的绑定——实战中的“排兵布阵”

任务绑定，其实就是亲和性的具体应用。但这里有个更实际的问题：到底哪些任务该绑在一起？哪些该分开？

我总结了一个简单的“三原则”，你可以参考：

  1. 高耦合任务绑一起：比如一个传感器采集任务和它的数据处理任务，频繁交换数据，绑在同一个核上可以减少IPC开销。
  2. 高实时任务独占一核：比如电机控制、音频流处理，这些任务对延迟敏感，最好给它一个专属核心。
  3. 低优先级任务分散开：后台日志、状态监控这类任务，可以分散到各个核心的剩余时间片里，别让它们扎堆。

我曾经在一个四核MCU项目上，把三个高实时任务分别绑到了Core0、Core1、Core2上，Core3专门跑通信协议栈和后台任务。结果系统跑得非常稳，几乎没有出现任务超时的情况。说白了，这就是“排兵布阵”的功劳。

注意： 绑定任务时，一定要考虑核心的中断负载。如果一个核心上绑了太多任务，同时还要处理高频中断，那这个核心可能会成为系统的瓶颈。我曾经见过一个项目，Core0上绑了5个任务，还挂着两个定时器中断，结果Core0的利用率飙到95%，其他核心却在“摸鱼”。这就是典型的“绑定失衡”。

4.3 核间通信（IPC）简介——让核心们“说上话”

多核系统里，核心之间不是孤岛。它们需要交换数据、同步状态、传递事件。这就用到了核间通信（IPC，Inter-Processor Communication）。

IPC的常见方式有几种：

IPC方式 特点 适用场景
共享内存 速度快，但需要同步机制（如自旋锁、信号量） 大数据量传输，如音频帧、图像数据
消息队列 异步通信，解耦性好 任务间传递控制命令、状态信息
核间中断（IPI） 低延迟，用于触发事件 唤醒另一个核心上的任务，或同步时钟
硬件信号量 硬件级原子操作，避免软件锁的开销 保护共享资源，如外设寄存器

我个人最常用的是共享内存 + 核间中断的组合。为什么？因为共享内存传输数据快，核间中断用来“敲门”——告诉另一个核心：“嘿，数据准备好了，快来取！”

举个例子，一个双核系统，Core0负责采集传感器数据，Core1负责处理数据并控制输出。流程是这样的：

  1. Core0把数据写入共享内存缓冲区。
  2. Core0触发一个核间中断，通知Core1。
  3. Core1的中断服务程序（ISR）里，从共享内存读取数据，然后处理。
  4. 处理完成后，Core1通过另一个共享标志位告诉Core0：“数据已取走，缓冲区可用。”

你看，整个过程没有用到复杂的锁机制，全靠硬件中断和共享内存配合，效率非常高。

核心要点： IPC的设计原则是“尽量减少核间通信的频率，而不是减少单次通信的数据量”。因为每次核间通信都有同步开销，频繁的小数据通信比一次大数据通信更消耗性能。所以，能批量传输的就批量传输，能合并消息的就合并。

4.4 避坑指南——我曾经踩过的三个坑

讲到这里，我想分享几个我亲身经历过的坑，希望能帮你少走弯路。

  • 坑一：共享内存不加保护。有一次，两个核心同时写同一个共享变量，结果数据被覆盖，系统出现随机崩溃。后来加了硬件信号量，问题解决。记住：共享内存一定要有同步机制，哪怕只是一个原子操作。
  • 坑二：核间中断处理时间过长。我在一个项目里，把大量数据处理逻辑直接放在了核间中断的ISR里，结果导致其他中断响应延迟。后来把ISR里只做“取数据+发信号量”，真正的处理交给一个高优先级任务，问题解决。
  • 坑三：亲和性设置过于死板。一开始我把所有任务都绑死了，结果某个核心负载过高，其他核心空闲。后来改为“软亲和性”——任务优先在指定核上运行，但如果该核忙，可以迁移到其他核。这样既保证了缓存命中率，又实现了负载均衡。

嗯，这些坑说起来都是泪。但踩过了，也就记住了。

4.5 小结

这一章我们聊了多核调度的三个核心概念：

  • CPU亲和性：让任务“粘”在合适的核上，减少缓存失效和资源竞争。
  • 任务绑定：根据任务的耦合度、实时性、负载情况，合理分配核心资源。
  • 核间通信（IPC）：通过共享内存、消息队列、核间中断等方式，让核心之间高效协作。

下一章，我们会深入实战，用具体的代码演示如何在双核MCU上实现一个灯光任务调度系统。到时候，你会看到亲和性和IPC是怎么落地到实际项目中的。

好，今天就到这里。有什么问题，欢迎在课程群里讨论。

← 上一章 📖 返回目录 下一章 →