我对FUSE的多线程读周期的理解是这样的：
....
.-> read --.
/ \
open ---> read ----+-> release
\ /
`-> read --'
....
即，文件open后，生成多个read个线程以读取文件的不同块。然后，当读完所需的所有内容时，会有一个最终的单release。所有这些都是open，read和release的定义，作为FUSE操作。
我正在创建一个将一种文件类型转换为另一种文件类型的覆盖文件系统。显然，没有任何索引的随机访问是一个问题;所以暂时，我采取流媒体方式。也就是说，在上面的模型中，每个读取线程将从开始开始转换过程，直到它到达正确的转换数据位以推出到读缓冲区。
这显然效率很低！要解决此问题，单个文件转换过程可以从open阶段开始，并使用互斥锁和读取光标（即，＃34;我已经消耗了这么多，到目前为止＆＃34;）读者线程可以用来强制顺序访问。也就是说，互斥锁被从当前光标位置请求数据的线程锁定，而所有其他读者线程必须等到轮到它。
我不明白为什么这对于流式传输文件不起作用。但是，如果任何随机/非顺序访问发生，我们就会遇到死锁：如果请求的偏移量超出当前光标位置或在当前光标位置之前，则互斥锁永远不会解锁为适当的读取器能够达到那一点。 （据推测，我们无法访问FUSE的线程，因此担任主管。此外，我无法通过强制文件成为FIFO来解决问题，因为FUSE不支持给他们写信。）
实际上，如果互斥锁被锁定且光标超出请求的偏移量（即＆＃34;无法倒带＆＃34;情况），我只能检测到何时发生这种情况。在这种情况下，我可以返回EDEADLK，但是没有办法检测＆＃34;快进＆＃34;请求无法满足。
冒着一个略带哲学的问题......我该怎么办？