一、多核系统概述：从单核到多核的演进、多核架构分类（SMP/AMP）、实时系统的需求与挑战
各位同学，咱们今天聊聊多核系统的来龙去脉。说实话，我入行那会儿，单核还是绝对的主流。那时候做嵌入式，能跑个200MHz的ARM9就算高端货了。后来呢？摩尔定律撞上了功耗墙，单核频率上不去了，大家开始往芯片里塞更多的核。嗯，这就是多核时代的起点。
1.1 从单核到多核：为什么非走这条路不可？
你想想看，单核处理器要提升性能，无非两条路：要么提高主频，要么优化架构。但主频一高，功耗就爆炸。我记得当年有个项目，用的单核芯片跑到1GHz，散热片烫得能煎鸡蛋。客户投诉说设备外壳温度超标，最后只能降频到800MHz用。
多核架构的出现，说白了就是「打不过就加入」——一个核跑不动，那就上两个、四个、八个。每个核跑低频，功耗可控，总吞吐量却上去了。这就是所谓的「频率墙」和「功耗墙」逼出来的路。
核心矛盾：单核性能提升的边际成本越来越高，多核并行成为性价比最优解。
我在项目中遇到过这样一个场景：一个视频处理任务，单核要跑满100% CPU才能勉强实时。换成四核后，每个核只跑30%负载，功耗降了一半，温度也稳了。这就是多核的威力。
1.2 多核架构分类：SMP vs AMP
多核系统不是简单地把几个核焊在一起就完事了。架构上，主要分两大类：SMP（对称多处理）和AMP（非对称多处理）。这两者的区别，我习惯用一个比喻来解释。
SMP（对称多处理）——就像几个厨师共用一个大厨房。所有核共享同一份内存、同一个操作系统。任务可以自由调度到任意核上。好处是编程简单，你写代码时基本不用操心哪个核在干活。坏处呢？缓存一致性、锁竞争，这些坑我踩过不少。
AMP（非对称多处理）——更像每个厨师有自己的小灶台。每个核跑独立的操作系统，甚至不同的操作系统。比如一个核跑Linux做应用，另一个核跑RTOS做实时控制。核间通信靠共享内存或消息队列。这种架构适合对实时性要求极高的场景。
| 特性 | SMP | AMP |
|---|---|---|
| 操作系统 | 单一OS，所有核共享 | 每个核可运行不同OS |
| 内存模型 | 统一内存空间 | 独立或部分共享 |
| 任务调度 | OS自动均衡 | 开发者手动分配 |
| 实时性 | 受OS调度影响 | 可精确控制 |
| 编程难度 | 较低 | 较高 |
| 典型应用 | 服务器、手机SoC | 工业控制、汽车ECU |
我的建议：如果你做消费电子，SMP是首选，开发效率高。如果是工业或汽车领域，AMP更靠谱。我曾经在一个机器人项目中用了SMP，结果实时任务被非实时任务干扰，导致电机控制抖动。后来改成AMP，一个核跑RTOS专门控制电机，问题就解决了。
1.3 实时系统的需求与挑战
实时系统，说白了就是「在规定时间内必须完成指定任务」。不是快就行，而是要可预测。你想想看，安全气囊必须在碰撞后几毫秒内弹出，晚一毫秒就是人命关天。
多核给实时系统带来了哪些挑战？我总结了几点：
- 核间干扰：一个核上的高优先级任务，可能被另一个核的缓存刷写或总线争用拖慢。这叫「干扰效应」，在单核时代根本不存在。
- 锁与同步开销：多核访问共享资源时，必须加锁。但锁一多，优先级反转、死锁就来了。我记得有个项目，因为一个自旋锁没处理好，导致系统偶尔卡死，查了三天才找到原因。
- 缓存一致性问题：核A改了内存里的数据，核B读到的却是旧值。这就是缓存一致性问题，后面我们会专门讲。
- 任务划分与绑定：哪些任务放哪个核？怎么保证关键任务不被干扰？这需要精细的亲和性设置。
避坑指南：我曾经在一个多核项目中，把所有中断都绑定到了核0上。结果核0忙得冒烟，其他核闲得发慌。后来才意识到，中断负载均衡也很重要。记住：多核不是万能药，用不好反而更糟。
实时系统的需求，我习惯用三个维度来衡量：
- 确定性：任务的最坏执行时间（WCET）必须可计算、可验证。
- 低延迟：中断响应时间、任务切换时间要尽可能短。
- 资源隔离：关键任务不能受非关键任务的影响。
嗯，这里要注意：多核系统里，这三个维度都会受到核间交互的影响。比如缓存一致性协议（MESI之类的）会在后台刷数据，这个时间你是控制不了的。所以做实时系统时，我建议尽量把关键任务和普通任务隔离开——要么用AMP，要么在SMP里做CPU亲和性绑定。
最后说一句：多核实时系统，不是把单核代码直接扔上去就能跑的。你得重新思考任务划分、同步机制、内存布局。后面我们会一步步深入这些话题。