Does python's fcntl.flock function provide blocking access to a file at the thread level?

Question

The Python fcnt module provides a method called [flock] [1] for proven file locking. This description reads:

Perform the op lock operation on the file descriptor fd (providing file objects The fileno () method is accepted as Well). See Unix Installation Guide (2) for details. (On some systems, this function is emulated using fcntl ().)

Searching the linux man page for the pack, this only applies to blocking the cross process, for example:

A call to flock () may be blocked if an incompatible lock is held by another process. To make a non-blocking request, include LOCK_NB (ORing) with any of the above operations.

So my question is: will flock () also provide safe thread locking and block multiple threads within the same process, as well as threads from different processes?

[1]: http://docs.python.org/library/fcntl.html#fcntl.flockfunction is emulated using fcntl ().)

Answer 1

flock locks do not care about threads - in fact, they do not care about processes. If you take the same file descriptor in two processes (inherited via fork), or the file lock process with this FD gets a lock for both processes. In other words, in the following code, both flock calls will return success: the child process locks the file, and then the parent process gets the same lock, not the lock, because they are both the same FD.

 import fcntl, time, os f = open("testfile", "w+") print "Locking..." fcntl.flock(f.fileno(), fcntl.LOCK_EX) print "locked" fcntl.flock(f.fileno(), fcntl.LOCK_UN) if os.fork() == 0: # We're in the child process, and we have an inherited copy of the fd. # Lock the file. print "Child process locking..." fcntl.flock(f.fileno(), fcntl.LOCK_EX) print "Child process locked..." time.sleep(1000) else: # We're in the parent. Give the child process a moment to lock the file. time.sleep(0.5) print "Parent process locking..." fcntl.flock(f.fileno(), fcntl.LOCK_EX) print "Parent process locked" time.sleep(1000) 

At the same time, if you lock the same file twice, but with different file descriptors, the locks will lock each other - regardless of whether you are in the same process or in the same thread. See Flock (2): 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. 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.

It is useful to remember that the Linux kernel, processes and threads are essentially the same thing, and they are usually handled by the same kernel-level APIs. For the most part, if syscall documents handle child / parent behavior, they will be preserved for streams.

Of course, you can (and probably should) test this behavior yourself.