请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：AM4378 工具/软件：Linux
我正在使用4.1内核(特别是来自02.00.02 SDK 的内核)在 AM4378的 Linux 用户空间中开发一个小型应用 、该内核与在 PRUSS1上运行的小型程序进行通信、我也使用 PRU 软件支持包进行开发。 我将 rpmsg 用于 PRU 通信、并且能够以这种方式向 PRU 发送大量数据、而不会出现任何明显的问题。 在某些情况下、我最终想要"清空"传入的 rpmsg 队列、这是通过从队列中读取消息来实现的、直到 PRU 上的一个非常紧密的循环中队列为空。 通常情况下、这种方法可以正常工作、但很少会导致无限循环、其中 PRU 不断从 rpmsg 队列中反复"读取"同一组消息。 即使在终止正在写入这些消息的 Linux 用户空间应用程序时也会继续执行此操作，这似乎排除了此应用程序重复发送同一组消息的可能性。
在我看来、这似乎强烈表明 rpmsg 堆栈本身正在发生某种竞争情况。 查看该代码的 PRU 侧、我注意 到在这一行中、 PRU 正在递增 Linux 内核用来确定使用的缓冲区索引、在 PRU 填充该条目的 idx 和 length 字段之前、哪些条目在使用的缓冲区表中包含需要处理的条目。 PRU 在填入这些字段后才会启动内核、但就我可以说、一旦启动、内核将处理当前使用的索引之前的所有已使用元素、 因此、如果 PRU 在内核开始响应第一个使用的元素时更新另一个使用的元素、则内核仍可以处理无效数据。 (不是100%确定这一点--内核端代码更难遵循。)
我在这里的问题是：
- PRU 软件支持包存储库中用于02.00.02 SDK 内核的正确标签/分支是什么？ (我在我自己的代码旁边签入了这些文件、但没有跟踪我复制这些文件的版本。)
- 在我所介绍的情况下、是否有某种机制无法阻止内核接收无效数据？
- 在将所有数据写入条目之前等待递增使用的索引是否足以解决此潜在问题？ (我对编译器重新排序赋值有点担心、因为似乎没有任何内容声明为易失性。)
- 是否有任何其他已知问题可以解释这种行为？ (实际上、我在思考这种潜在的竞争状况如何实际导致我实际看到的问题方面遇到了一些困难。)
