0

this is a design question more than a coding problem. I have a parent process that will fork many children. Each of the children is supposed to read and write on the same text file.

How can we achieve this safely?

My thoughts:

create the file pointer in the parent, then create a binary semaphore on it. And processes will compete on obtaining the file pointer and write on the file. In the read case i don't need a semaphore.

Please tell me if i got it wrong.

I am using C under linux. Thank you.

user2157735
  • 1
  • 1
  • Might be a dup but worth reading anyway (http://stackoverflow.com/questions/2057784/locking-files-in-linux-with-c-c) – Andrew White Mar 11 '13 at 16:51
  • Search on file and/or record locking and determine if that is suitable before exploring more complicated schemes. – Duck Mar 11 '13 at 17:23
  • 1
    I would avoid using a single textual file on that case (because writing in the middle of a textual file means mostly inserting text, and that changes the size of the entire file and the offsets handled by other processes). Maybe sharing e.g. a `gdbm` index file, or some database, would be more appropriate... – Basile Starynkevitch Mar 11 '13 at 18:06

2 Answers2

1

POSIX systems have kernel level file locks using fcntl and/or flock. Their history is a bit complicated and their use and semantics not always obvious but they do work, especially in simple cases. For locking an entire file, flock is easier to use IMO. If you need to lock only parts of a file, fcntl provides that ability.

As an aside, file locking over NFS is not safe on all (most?) platforms.

man 2 flock

man 2 fcntl

http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems

Also, keep in mind that file locks are "advisory" only. They don't actually prevent you from writing/reading/etc to a file if you bypass acquiring the lock.

acarlow
  • 914
  • 1
  • 7
  • 13
0

If writers are appending data to the file, your approach seems fine (at least up until the file becomes too large for the file system).

If writers are doing file replacement, then I would approach it something like this:

  • The reading API would check the time of last modification (with fstat()) against a cached value. If the time has changed, the file is re-opened, and the cached modification time updated, before the read is performed.

  • The writing API would acquire a lock, and write to a temporary file. Then, the actual data file is replaced by calling rename(), after which the lock is released.

If writers can write anywhere in the file, then you probably want are more structured file than just plain text, similar to a database. In such a case, some kind of reader-writer lock should be used to manage data consistency and data integrity.

jxh
  • 69,070
  • 8
  • 110
  • 193