我正在使用 CMX-RTX RTOS 和 Elm Chan FatFS。在任务排成一行到达文件系统之前，一切都很好。
对于熟悉 Chan FatFS 的人，我修改了 ENTER_FS 和 LEAVE_FS 宏来获取和释放资源。如果一个任务试图进入 FS 并且资源是自己的，它将被置于等待直到资源被释放。
我开始怀疑这是处理从多个任务访问 FS 的最佳方式。我有多个实例，其中 FS 产生故障，甚至对 SD 的简单命令也得到不正确的响应。如果我仅将 1 个任务限制为访问 FS，则不会发生这些故障。
要解决主要问题，大家对多任务 FS 访问有何想法/建议？例如我最初使用的更精细的方法？或者可能是一个单一的任务，它会被不同的任务标记以访问 FS？
由于大多数访问都是读取，因此显而易见且简单的改进是多读取器、单写入器。进一步的改进是对根 FAT 目录进行特殊处理，并创建一个旁路，以便其他地方的写入不会阻塞根目录的读取。（这也可能包括根目录的 R/W 缓存）
我使用一个线程通过 FatFS 访问我的 SD 卡。正如你所说，它运作良好。我使用主线程来运行文件系统，因为它具有最大的堆栈（因为它必须运行 crt、C++ 静态 ctor 和其他东西）。main() 成为一个线程，启动运行应用程序的所有其他线程，然后运行一个文件系统循环来处理来自生产者-消费者队列的请求。
任何需要文件操作的线程都必须将“FSrequest”对象排队到 FS 线程。当请求出现在队列中时，FS 线程会按顺序处理它们。所有需要 FS 的线程都从 FSnotifiable 派生，它本身是从 FSrequest 派生的类，该类具有 FSnotify 方法，该方法将 FSrequest 作为参数。FS 线程从队列中弹出 FSrequest，按照“command”枚举成员的请求对其进行处理，加载带有 null 或错误字符串指针的“error”成员，然后以完成的 FSrequest 作为参数调用 FSnotify 方法。
通常， FSnotify() 发出信号量，原始线程正在等待该信号量。
编辑：这都是垃圾，因为这是交流问题：（（
我会再尝试：
好的，所以没有类:( 声明一个“FSrequest”结构来表示一个 FS 请求/响应。它应该有一个枚举来表示所需的操作，以及一个“完成”回调函数来填充原始线程。它会也可能有一个缓冲区指针，（对于那些需要缓冲区来读取/写入，或保存错误消息失败的操作）和一个成功/失败布尔值。
使用从生产者-消费者队列结构/代码中弹出的一个线程来处理文件系统。如果一个线程想要进行 FS 操作，它需要声明一个 FS 请求，填写详细信息并将其排队到 FS 线程。它应该将完成回调指向一个发出信号量的函数。请求线程在信号量上等待来自 FS 线程的完成通知。FS 线程执行请求的任何操作，填写成功/失败/错误，然后调用完成回调。