CODEWITHSUNDEEP
multithreadingfileiolockingposix
matt-pielat
matt-pielat

Reputation: 1799

POSIX-compliant file locking (within a single process)?

I'm making a client/server system where clients can download and upload files to the server (one client can do several such operations at once). In case of a client crash it has to resume its interrupted operations on restart.

Obviously, I need some metadata file that keeps track of current operations. It would be accessed by a thread every time a chunk of data is downloaded/uploaded. Also, the client application should be able to print all files' download/upload progress in %.

I don't mind locking the whole meta-file for a single entry (that corresponds to single download/upload operation) update but at least reading it should allow thread concurrency (unless finding and reading a line in a file is fast).

This article says that inter-process file locking sucks in POSIX. What options do I have?

EDIT: it might be clear already but concurrency in my system must be based on pthreads.

Upvotes: 0

Views: 92

Answers (1)

Dummy00001
Dummy00001

Reputation: 17420

This article says that inter-process file locking sucks in POSIX. What options do I have?

The article correctly describes the state of inter-process file locking. In your case, you have single process, thus no inter-process locking is taking place.

[...] concurrency in my system must be based on pthreads.

As you say, one of the possibilities, is to use a global mutex to synchronize accesses to the meta file.

One way to minimize the locking, is to make the per-thread/per-file entry in the meta-file of predictable size (for best results aligned on the file-system block size). That would allow following:

  • while holding the global mutex, allocate the per-file/per-thread entry in the meta-file by appending it to the end of the meta-file, and saving its file offset,
  • with the file offset, use the pread()/pwrite() functions to update the information about the file operations, without using or affecting the global file offset.

Since every thread would be writing into its own area of the meta-file, there should be no race conditions.

(If the number of entries has upper limit, then it is also possible to preallocate the whole file and mmap() it, and then use it as if it was plain memory. If application crashes, the most recent state (possibly with some corruptions; application has crashed after all) would be present in the file. Some applications to speed-up restart after software crash, go as far as keep the whole state of the application in a mmap()ed file.)

Another alternative is to use the meta-file as "journal": open the meta-file in append mode; as entry, write status change of the pending file operations, including start and end of the file operations. After the crash, to recover the state of the file transfers, you "replay" the journal file: read the the entries from the file, and update the state of the file operations in the memory. After you reach the end of the journal, the state in memory should be up-to-date and ready to be resumed. The typical complication of the approach, since the journal file is only written into, is that it has to be clean-up periodically, purging old finished operations from it. (Simplest method is to implement the clean-up during recovery (after recovery, write new journal and delete the old) and then periodically gracefully restart the application.)

Upvotes: 0

Related Questions