Classic AUTOSAR深入浅出系列 - 【第二十篇 补充】为什么同 Task 可以传指针，不同 Task 必须 copy？
为什么「同 Task 可以传指针，不同 Task 必须 copy」？
一句话版本先给你一个不糊弄人的结论：
不是 RTE 想不想 copy，而是 OS 是否能保证“同一时间只会有一个执行上下文访问这份数据”。
而这个保证，只有在同一个 Task 内，OS 才能给得出来。
下面我们一步一步来。
一、先明确一个前提：Runnable 本质是普通 C 函数
void Runnable_Control(void)
{
uint16 speed;
Rte_Read_Speed(&speed);
if (speed > LIMIT)
{
Rte_Write_TorqueRequest(REDUCE);
}
}
从 C 语言角度看：
-
Rte_Read_*/Rte_Write_*只是函数调用 -
所谓“通信”，最终一定落到：
- 读某块内存
- 写某块内存
RTE 的难点从来不在“函数调用”，
而在 这块内存在什么时候、被谁、以什么顺序访问。
二、同一个 Task：为什么 RTE 敢直接传指针？
场景设定
- Runnable A（Sender）
- Runnable B（Receiver）
- 都被映射到 同一个 OS Task
- 都是
TimingEvent，10ms 周期
Task_10ms:
├─ Runnable_A()
└─ Runnable_B()
OS 在这里给了什么“硬保证”？
在 Classic AUTOSAR OS 中：
-
一个 Task 在任意时刻只能执行一个 Runnable
-
非抢占式 Task：
- Runnable A 执行完 → Runnable B 才能执行
-
抢占式 Task：
- 只要没有更高优先级 Task 抢占
- 同一个 Task 内依然是串行的
也就是说：
在 Task_10ms 的一次调度窗口内，不可能出现两个 Runnable 同时访问同一份 RTE 数据。
RTE 可以做的最激进优化
于是 RTE 生成代码时可以放心地这样干：
static uint16 Rte_Buffer_Speed;
void Rte_Write_Speed(uint16 data)
{
Rte_Buffer_Speed = data;
}
void Rte_Read_Speed(uint16* data)
{
*data = Rte_Buffer_Speed;
}
甚至更狠一点（配置允许时）：
- 直接把
Rte_Buffer_Speed的地址 - 传给另一个 Runnable 用
📌 关键点：
这里“安全”的根本原因不是 RTE 多聪明，而是 OS 已经保证了执行顺序。
三、不同 Task：为什么指针立刻变成“炸弹”？
现在换一个非常常见的真实工程场景。
场景设定（⚠️高频踩坑）
-
Runnable A
TimingEvent，10ms- 在
Task_10ms（低优先级）
-
Runnable B
DataReceivedEvent- 在
Task_ComRx（高优先级）
Task_ComRx (High)
└─ Runnable_B() ← 由 CAN Rx ISR 触发
Task_10ms (Low)
└─ Runnable_A() ← 周期触发
两者通过一个 Sender-Receiver Signal 通信。
时间线上发生了什么（这是重点）
t0: Task_10ms 开始
Runnable_A() 正在执行
└─ Rte_Write_Speed()
t1: CAN Rx 中断到来
→ 激活 Task_ComRx
→ 抢占 Task_10ms
t2: Runnable_B() 执行
└─ Rte_Read_Speed()
t3: Runnable_B() 执行结束
Task_ComRx 退出
t4: Task_10ms 恢复
Runnable_A() 继续执行
⚠️ 注意：
Runnable_A 的 Rte_Write_Speed()
可能还没写完！
如果 RTE 只是“传指针”，会发生什么？
假设 RTE 生成了这种代码（这是绝对不允许的）：
uint16* Rte_Ptr_Speed;
void Rte_Write_Speed(uint16* ptr)
{
Rte_Ptr_Speed = ptr;
}
void Rte_Read_Speed(uint16* out)
{
*out = *Rte_Ptr_Speed;
}
那在 t1 ~ t2 之间：
- Sender 正在修改
*Rte_Ptr_Speed - Receiver 已经开始读
*Rte_Ptr_Speed
结果可能是：
- 读到一半更新的数据
- 读到逻辑上“不存在”的状态
- 在多字节数据（struct）下尤其致命
📌 这已经不是“数据延迟”问题，而是“数据不一致”问题。
四、RTE 的选择：宁可慢，也不能错
所以只要满足以下任一条件：
- 不同 OS Task
- 不同优先级
- 不同触发源（Timing / Data / Mode）
RTE 就必须假设：
“我完全无法预测 Sender 和 Receiver 的执行时序。”
于是只能选 最保守方案：
双 Buffer / Copy 语义
static uint16 Rte_Buffer_Speed;
void Rte_Write_Speed(uint16 data)
{
SuspendAllInterrupts();
Rte_Buffer_Speed = data;
ResumeAllInterrupts();
}
void Rte_Read_Speed(uint16* data)
{
SuspendAllInterrupts();
*data = Rte_Buffer_Speed;
ResumeAllInterrupts();
}
或者更高级一点：
- Disable OS interrupts
- 或使用 OS Resource
- 或使用 implicit locking（RTE 内部）
📌 重点不是“copy 本身”，而是 copy 带来的“时序隔离”。
五、为什么“同 Task”与“不同 Task”的边界这么重要？
把 RTE 的判断逻辑总结成一句工程规则：
只要 OS 能证明“这段时间内不会被别人打断”，RTE 就敢偷懒。
一旦证明不了，RTE 就必须兜底。
这也是为什么：
- 把 Runnable 随意拆到不同 Task
→ 通信成本立刻上升 - 乱用 DataReceivedEvent
→ 隐式引入跨 Task 通信 - 不理解 Task / Event 映射
→ 性能和实时性莫名变差
六、总结
RTE 是否 copy，从来不是“配置习惯”的问题，而是 OS 调度语义是否能为数据一致性背书。
同一个 Task 内，Runnable 的串行执行是 OS 保证的事实，RTE 可以激进优化；
一旦跨 Task、跨优先级、跨触发源，RTE 就必须假设最坏情况，用 copy 和保护机制兜底。理解这一点，才能真正把 OS、RTE 和应用代码“连成一个整体”。
本文地址：https://www.yitenyun.com/4919.html
