等过了事件，为什么还没等到数据？

系列目录 · 资源与调度 · Read in English

“我已经加了等待，怎么还能读到没算完的门值？”

“你等的是哪个事件？”

“一个 ready 事件。”

“它到底覆盖了哪条真实工作？”

最后这个问题，往往比前面十行同步代码都重要。事件名字表达的是愿望，设备执行的是协议。一个叫“数据就绪”的标记，只有与生产数据的真实命令建立了正确关系，才真的能代表数据就绪。

循环单元天然有两种并行性

以教学形式表示某一组门计算：

1
2
3
4

a_t = W_x * x_t
b_t = W_h * h_(t-1)
gate_t = activation(a_t + b_t)
h_t = combine(gate_t, ...)

输入投影 a_t 不读取新隐藏状态，可能有提前计算机会；循环投影 b_t 必须等待上一轮状态更新完成。若矩阵引擎 M 和向量引擎 V 可以异步运行，合理调度会尽量让 M 在 V 更新状态时先做不依赖状态的工作。

于是一个诱人的顺序出现了：先发射 a_t，再等待上一轮隐藏状态，然后发射 b_t，最后发送“门值准备好”的事件。这个顺序看起来充分利用了空闲时间，数学依赖图也没有少边。

但同步事件究竟表示“此前全部工作完成”，还是只跟踪一个显式范围中的命令，不能靠数学图决定。

空的依赖范围为什么危险

假设一种教学设备把事件绑定到 begin 和 end 之间的实际命令。那么下面的代码：

1
2
3
4
5

issue work_A
issue work_B
begin event_E
end event_E
other_engine waits event_E

未必等价于等待 work_A 和 work_B。事件范围里没有真实工作，设备可能认为它已经完成，或者它只代表一个空批次。此时等待本身完全合法，却没有承诺读者真正需要的条件。

这里的协议是教学抽象，不能拿去解释所有事件 API。有些系统的队列尾事件确实涵盖此前全部命令；有些则需要显式依赖范围。工程上必须读目标协议与代码实现，不能因为都叫 event 就假设语义相同。

已核实的提交注释明确指出，原来的空依赖范围不能保证向量侧观察到两项门计算都已完成。修复在循环的相关分支中调整顺序：先等待隐藏状态，发射循环投影，再建立就绪范围，把另一个需要执行的输入投影放在范围之中，然后释放事件。这样在普通路径上，范围围住了真实矩阵工作。

这次修改牺牲了哪一部分机会

原先尝试把不读隐藏状态的投影提前，目的是避免矩阵引擎在向量更新尾部空闲。修复把这项工作移到较晚位置，可能减少这种重叠。

这是非常典型的正确性与性能取舍：一个看似更并行的计划，如果它的完成通知不能覆盖真实写入，就不具备可用性能。先恢复可证明的顺序，再寻找合法重叠，才有可比较的基线。

值得注意的是，该修复很小，两个不同标题的提交呈现相同文件差异。不能据此写成“先发现一种问题，再解决另一种问题”的两次独立事故。公开叙述应该把它们当作同一技术修复在历史中的重复出现，除非有额外证据能证明不同背景。

一条修复，不能替全部模式作保

循环内核通常有首步、后续步、融合门、输入投影预计算、额外搬运等分支。相关修改落在其中一个循环阶段，并且输入投影是否发射仍然受条件控制。

因此可以核实的结论是：该路径的命令顺序发生了变化，作者以真实命令覆盖事件为理由修正同步。不能进一步声称所有配置下再也没有空范围，或者融合和预计算模式已经得到同样程度的验证。

这也是回归测试应该按模式展开的原因。只测普通循环路径，可能错过“本轮投影已预先计算，因此本应位于事件范围内的命令被省掉”这种条件变化。模式开关改变的不只是算术数量，还会改变同步证据。

把事件当成一份可以检查的证明

评审时可以给每个同步对象写四项说明：

1. 它证明哪些结果已经可读？
2. 哪些命令真正写出这些结果？
3. 哪些队列顺序或依赖范围把命令连接到事件？
4. 哪些消费者依靠它开始执行？

如果第一项很宽泛，第二项找不到具体命令，这个事件就值得怀疑。如果事件等待者不止一个，还要核对消费计数与复用时机，避免把上一轮事件误用于下一轮。

在循环里，最好给事件加上概念上的迭代编号 E_t。即便物理槽复用，也应能解释为什么 E_t 的所有消费者结束后，槽才会承担 E_(t+1)。只检查寄存器最终归零，不能单独证明跨迭代语义正确。

重新设计一个最小反例

让上一轮隐藏状态更新很慢，输入投影很快，循环投影中等。若向量引擎等待一个没有覆盖真实矩阵工作的事件，它可能在循环投影结束前读取门值。

模拟器不必计算真正矩阵，只需为输出区写版本号：输入投影写入 input_version=t，循环投影写入 state_version=t，门函数启动时检查两个版本都等于 t。这样即使最后数值偶然相同，也能暴露读取旧结果的时序错误。

接着缩短或延长不同引擎耗时，遍历合法队列交错。如果错误只在某种速度比例下出现，就能说明为什么一个固定延迟模型可能掩盖同步缺口。

为什么盯着 wait 数量，很容易走错方向

假设优化前有五次等待，优化后有四次。这个数字本身不能回答少掉的一次是冗余同步，还是丢掉了必要完成关系。反过来，增加一次等待也可能降低总时间：如果旧程序存在循环等待或长期阻塞，正确建立生产与消费顺序，反而让队列更容易持续前进。

更可靠的调试方式是对每次读取标出最后写者，然后检查它们之间的证明路径。路径可以包含生产者队列顺序、事件完成、消费者等待和消费者队列顺序。只有整条路径都合法，才能说这次读取受保护。某个漂亮的事件名不能替代路径中缺失的一段。

对循环还要问“哪个版本”。第 t 轮的门计算可能确实等到了某个隐藏状态更新，但如果等到的是前一轮已被复用的通知，数值依赖仍然错误。把物理事件槽与逻辑事件版本分开记录，往往能让日志更有解释力。

若无法获得真实设备的时序观测，至少可以静态列出每种模式会发射哪些命令，标出条件分支删掉了哪些工作，再审查事件范围是否随之失去含义。这样做不能取代硬件验证，却能在上板之前发现明显的空范围和版本混用问题。

性能实验也应在这些语义检查之后进行。否则一个更短的执行时间，可能只是某个消费者提前读了旧结果。错误程序少等了一会儿，不是值得保留的优化成绩。

回归矩阵与性能观察

对于性能，建议同时统计总时延、矩阵引擎空闲片段、向量等待时间，以及同步命令数量。观察到某条队列更忙，不等于模型更快；它可能只是提前做了随后仍要等待的工作。

后续优化可以研究把合法的输入投影提前，同时为循环投影提供可靠完成证明，或利用明确的队列尾语义。但这些只是设计方向，不能冒充提交已经完成的优化。

“我已经等待了”不是同步证明的终点。下一句必须是：“这个等待为什么覆盖了我即将读取的那几次写入？”

返回系列目录 · 上一篇 · 下一篇

• ← Previous Post
• Next Post →