Is that correct that a mutex object in Linux cannot be used for cross process synchronization as opposed to its Windows counterpart?
If that is true - what was the idea to limit mutex synchronisation functionality on Linux?
3
-
1or it is the other way around: windows mutex was implemented with more functionality than the linux mutex– ratchet freakCommented Jun 8, 2013 at 11:25
-
you could say that, but from what I remember the first version of linux was released when windows os was already out. just interested why there a difference in the functionality ...– MittenCommented Jun 8, 2013 at 14:40
-
but was a mutex implementation involved in both releases? don't forget upgraded that M$ would have done– ratchet freakCommented Jun 8, 2013 at 15:00
Add a comment
|
2 Answers
The difference is kind of "made up", on windows MUTEX is very rarely used, and even then no really for sync but to discover already runnin instance of the program. What has wide use is CRITICAL_SECTION, and it is close equivalent of recursive mutex on linux, solaris and others.
-
3I have seen the "discover an already running instance" on unix based implemented by opening a port. Since only one process can hold a port open, the second process knows the first process exists and can exchange communication with it (or refuse to start up because only one instance should be running at a time).– user40980Commented Jun 9, 2013 at 1:20
-
A more modern (and probably also more robust) approach to this would be registering a D-Bus object. Commented Nov 8, 2015 at 21:50
Linux Mutexes can be used for cross process synchronization. Been there, done that, very useful. The Mutex must be accessible to the processes concerned, such as being in a shared memory block. The Mutex could also not be shared, and therefore private to the process that created it. The Mutex functionality in Linux is not limited.
Windows Mutexes are system objects. Any process can use the Mutex if it knows the name of the Mutex (in the case of a named Mutex), or if it has a handle to it.
Critical Section is functionally equivalent to an unshared Mutex in Linux, but is not a Mutex. You can use a mutex to do the job of Critical Section, albeit a bit overkill, but you can not get the interprocess capabilities of a Mutex from Critical Section (or can you?).
Mutex is not rarely used; a snapshot of my system (using Sysinternal's WinObj) shows 100 mutexes, 173 critical sections, and only 8 semaphores. And while using a Mutex to indicate a process is running (and thereby prevent instantiation of another copy of that process) is probably the most widely known usage of a Windows Mutex, and a valid, if course-grained, synchronization techninque, a quick glance at the list of mutexes on my machine reveals other usages, one of the most common being to control access to cache of some sort (browser, SVN, etc.)
I personally disagree with the usage of a port to discover processes. Just because port 61348 is in use doesn't mean the process I expect to be there is the one holding the port. Unless the process requires that port, such as server listening on a well known port, there is not enough information to decide whether or not to instantiate.
