78

Is there any easy way to have a system-wide mutex in Python on Linux? By "system-wide", I mean the mutex will be used by a group of Python processes; this is in contrast to a traditional mutex, which is used by a group of threads within the same process.

EDIT: I'm not sure Python's multiprocessing package is what I need. For example, I can execute the following in two different interpreters:

from multiprocessing import Lock
L = Lock()
L.acquire()

When I execute these commands simultaneously in two separate interpreters, I want one of them to hang. Instead, neither hangs; it appears they aren't acquiring the same mutex.

Improve this question
1

6 Answers 6

Reset to default
50

The "traditional" Unix answer is to use file locks. You can use lockf(3) to lock sections of a file so that other processes can't edit it; a very common abuse is to use this as a mutex between processes. The python equivalent is fcntl.lockf.

Traditionally you write the PID of the locking process into the lock file, so that deadlocks due to processes dying while holding the lock are identifiable and fixable.

This gets you what you want, since your lock is in a global namespace (the filesystem) and accessible to all processes. This approach also has the perk that non-Python programs can participate in your locking. The downside is that you need a place for this lock file to live; also, some filesystems don't actually lock correctly, so there's a risk that it will silently fail to achieve exclusion. You win some, you lose some.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Logical place for the lock file is /var/lock - however if there are going to be a vast number of locking operations, I suggest /tmp as not all systems have /var/lock in tmpfs ramdisk.
Not all systems have /tmp in tmpfs ramdisk either; my install of OS X does not seem to. Good points all the same, though.
he was asking about linux and most (if not all) of the major modern linux distros have /tmp in /tmpfs - none have /var/lock by default IIRC.
My Debian Squeeze install doesn't have a tmpfs /tmp either. It's actually got tmpfs on /dev/shm, which feature I've also seen on Fedora. It probably doesn't much matter in the end, as long as the location is documented.
Which filesystems don't lock correctly? Or, where can I find info on which filesystems don't lock correctly?
|
29

My answer overlaps with the other answers, but just to add something people can copy-paste, I often do something like this.

class Locker:
    def __enter__ (self):
        self.fp = open("./lockfile.lck")
        fcntl.flock(self.fp.fileno(), fcntl.LOCK_EX)

    def __exit__ (self, _type, value, tb):
        fcntl.flock(self.fp.fileno(), fcntl.LOCK_UN)
        self.fp.close()

And then use it as:

print("waiting for lock")
with Locker():
    print("obtained lock")
    time.sleep(5.0)

To test, do touch lockfile.lck then run the above code in two or more different terminals (from the same directory).

UPDATE: smwikipedia mentioned my solution is unix-specific. I needed a portable version recently and came up with the following, with the idea from a random github project. I'm not sure the seek() calls are needed but they're there because the Windows API locks a specific position in the file. If you're not using the file for anything other than the locking you can probably remove the seeks.

if os.name == "nt":
    import msvcrt

    def portable_lock(fp):
        fp.seek(0)
        msvcrt.locking(fp.fileno(), msvcrt.LK_LOCK, 1)

    def portable_unlock(fp):
        fp.seek(0)
        msvcrt.locking(fp.fileno(), msvcrt.LK_UNLCK, 1)
else:
    import fcntl

    def portable_lock(fp):
        fcntl.flock(fp.fileno(), fcntl.LOCK_EX)

    def portable_unlock(fp):
        fcntl.flock(fp.fileno(), fcntl.LOCK_UN)


class Locker:
    def __enter__(self):
        self.fp = open("./lockfile.lck")
        portable_lock(self.fp)

    def __exit__(self, _type, value, tb):
        portable_unlock(self.fp)
        self.fp.close()
Improve this answer

10 Comments

Any specific reason why you use "rb" and not "wb"?
@theV0ID flock doesn't require write access so there's no need to request it. In fact the 'rb' is not required, so I've removed it thanks for the question!
But by using "wb" you would omit the necessity to run touch lockfile.lck on a terminal first, right?
I tend to want the file created first, generally by the super-user so the individual workers can't delete it. I also want to avoid something with greater privileges coming and writing the file before any workers start, potentially denying them access. I consider the job of creating that file down to my 'installer' (for want of a better word), and my preference is to see any problems with that file creation at install time instead of run-time when it's hard to debug. But if it's right for your application, go for it!
@Mattkwish thanks, but I would advise you not to do this. The remove being outside of any lock can happen any time, and if it happens immediately after the open, the file will be deleted from the public filesystem but with the lock associated with the handle to the private file. Therefore you will have two separate files in play, and it's no longer global.
|
24

Try ilock library:

from ilock import ILock

with ILock('Unique lock name'):
    # The code should be run as a system-wide single instance
    ...
Improve this answer

7 Comments

... or directly via portalocker: with portalocker.TemporaryFileLock('filename.lock'): ...
@KT. TemporaryFileLock has race issues. Also, ILock support re-entrance.
Are you sure about the race issues? It seems to me both ILock and portalocker.Lock use exactly the same strategy of first doing open and then simply calling portalocker.lock on the handle to gain exclusivity. Where would the latter implementation miss anything to cause a race issue?
There can be an unexpected exception raised in case when file is deleted
I see, you are referring to the "WindowsError" catching piece in your code. It would probably make sense to add this try-catch to portalocker as well then. If you then also add a TemporaryFileRLock (which is a matter of 10 lines), the need for maintaining a separate library would probably go away.
|
14

The POSIX standard specifies inter-process semaphores which can be used for this purpose. http://linux.die.net/man/7/sem_overview

The multiprocessing module in Python is built on this API and others. In particular, multiprocessing.Lock provides a cross-process "mutex". http://docs.python.org/library/multiprocessing.html#synchronization-between-processes

EDIT to respond to edited question:

In your proof of concept each process is constructing a Lock(). So you have two separate locks. That is why neither process waits. You will need to share the same lock between processes. The section I linked to in the multiprocessing documentation explains how to do that.

Improve this answer

3 Comments

Thanks, but "multiprocessing" doesn't appear to be what I need; see the edited question.
The section you linked to appears to show how a master process can spawn 10 processes, passing a Lock object to each one it creates. My use case is different, as there is no master process spawning subprocesses. In my case, each process is invoked completely independently, but they must still coordinate.
Shared memory with a configured numeric address may be the only option if there is no relationship between peers but they still need a shared mutex. The mutex object can then live in the shared memory segment. There may be no Python API for this; if not you may have to go native. Also confirm that PThreads supports this use case fully; I worry it may not. Also, to me this is a design smell; it seems like you should be either using threads and mutexes, or a separate process like redis or riak to arbitrate.
7

Just to add a one to the list, there's the posix_ipc library, which has a Semaphore class.

A Semaphore with a count of 1 can be used as a Mutex. To complete the threading trio, the SystemEvent library makes use of posix_ipc and provides an Event as well.

I'd also note that this doesn't poll your hard drive either!

Improve this answer

1 Comment

From a different source I also found this library as most useful for the origial problem. In my case: 2-3-4 python programs (the same progam, started 2-3-4 times with different parameters) - and they have to use a non-thread safe resource. POSIX_IPC was the easiest solution by far. No file-system affected things are needed.
1

For a system-wide mutex that enables the synchronization of absolutely separate processes (i.e., to INCLUDE Linux processes that do NOT belong to the same processes tree), simply use fcntl.flock. I suppose that using a memory file under Linux' /run/shm folder may make it perform faster.

See more here.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.