我正在创建一个客户端/服务器系统，客户端可以将文件下载并上传到服务器（一个客户端可以同时执行多个此类操作）。如果客户端崩溃，它必须在重新启动时恢复其中断的操作。
显然，我需要一些跟踪当前操作的元数据文件。每次下载/上传一大块数据时，它都会被一个线程访问。此外，客户端应用程序应该能够以％。
打印所有文件的下载/上传进度我不介意将整个元文件锁定为单个条目（对应于单个下载/上传操作）更新，但至少读取它应该允许线程并发（除非查找和读取文件中的行很快）。
This文章称，进程间文件锁定在POSIX中很糟糕。我有什么选择？
编辑：它可能已经很清楚，但我的系统中的并发必须基于pthreads。
答案 0 :(得分：0)
本文称POSIX中的进程间文件锁定很糟糕。我有什么选择？
本文正确描述了 inter -process文件锁定的状态。在您的情况下，您有单个进程，因此没有进行进程间锁定。
[...]我的系统中的并发必须基于
pthreads。
正如您所说，其中一种可能性是使用全局互斥锁来同步对元文件的访问。
最小化锁定的一种方法是使元文件中的每线程/每个文件条目具有可预测的大小（以便在文件系统块大小上对齐最佳结果）。这将允许以下：
由于每个线程都会写入元文件的自己区域，因此不应存在竞争条件。
（如果条目数有上限，那么也可以预先分配整个文件并mmap()，然后将其用作普通内存。如果应用程序崩溃，最近的状态（可能有一些损坏;应用程序毕竟崩溃了）将出现在文件中。一些应用程序在软件崩溃后加速重启，尽量将应用程序的整个状态保存在mmap() ed文件中。）
另一种选择是使用元文件作为＆＃34; journal＆＃34;：以追加模式打开元文件;作为条目，写入挂起文件操作的状态更改，包括文件操作的开始和结束。崩溃后，为了恢复文件传输的状态，你可以重播＆＃34;日志文件：从文件中读取条目，并更新内存中文件操作的状态。到达期刊末尾后，内存中的状态应该是最新的并准备好恢复。由于只写入日志文件，因此该方法的典型复杂之处在于必须定期清理它，从中清除旧的完成操作。 （最简单的方法是在恢复期间实现清理（恢复后，编写新日志并删除旧日志），然后定期正常地重新启动应用程序。）