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?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.