4

I'm working on a multithreaded application where multiple threads may want exclusive access to the same file. I'm looking for a way of serializing these operations. I was planning to use flock, lockf, or fcntl locking. However it appears that with these methods an attempt to lock a file by a second thread when a first thread already owns the lock will be granted, because the two threads are in the same process. This is according to the manpages for flock and fnctl (and I guess in linux lockf is implemented with fnctl). Also supported by this other question. So, are there other ways of locking a file in linux which works at a thread-level instead of a process-level?

Some alternatives that I came up with which I do not like are:

1) Use a lockfile (xxx.lock) opened with O_CREAT | O_EXCL flags. This call will succeed only in one thread if there is contention. The problem with this is that then other threads have to spin on the call until they achieve the lock, meaning that I have to _yield() or sleep() which makes me think this is not a great option.

2) Keep a mutex'ed list of all open files. When a thread wants to open/close a file it has to lock the list first. When opening a file, it searches the list to see if it's open. This sounds particularly inefficient because it requires a significant amount of work even if the file is not owned yet.

Are there other ways of doing this?

Edit: I just discovered this text in my system's manpages which isn't in the online man pages:

If a process uses open(2) (or similar) to obtain more than one descriptor for the same file, these descriptors are treated independently by flock(). An attempt to lock the file using one of these file descriptors may be denied by a lock that the calling process has already placed via another descriptor.

I'm not happy about the words "may be denied", I'd prefer "will be denied" but I guess it's time to test that.

Community
  • 1
  • 1
cheshirekow
  • 4,797
  • 6
  • 43
  • 47
  • Memcached supports atomic key operations, you can build distributed locking strategies around that. :) I know it may sound wacky, but it works nicely, especially if you have programs spread across a network. – Dave S. Feb 19 '13 at 17:13
  • Certainly out of the box. I've looked at memchached before but haven't found a use for it yet. It sounds like a bit of a sledgehammer, but I will certainly keep that in mind. Thanks for the suggestion. – cheshirekow Feb 19 '13 at 17:49
  • Do you need advisory locks only, or real file locks (so that any process would be denied access to the locked file)? If advisory only, you can just use pthread_mutex, or pthread_mutex in combination with file locks if you want both inter-thread and inter-process. – Yevgeniy P Jun 11 '16 at 03:03
  • Actually a combination of pthread_mutex and file locks would work with real locks also, assuming all threads in your app follow this protocol. – Yevgeniy P Jun 11 '16 at 03:05

0 Answers0