[interprocess] named mutex clean up
Does calling named_mutex::remove() have consistent cross-platform behaviour? The reason I ask is that I am trying to use a named mutex for an "I'm the only process" check. That is, the process takes a shared lock on the named mutex (at start up), then, at points within the program, it attempts to get an exclusive lock in order to perform the check/actions. When finished, the mutex is returned to a shared lock. The problem is, if a process dies in some unforeseen manner - and does not get to call named_mutex::remove() - the named_mutex is left orphaned in the system (in a shared lock) such that other processes can never get an exclusive lock. On the Windows platform, I've found I can call named_mutex::remove() at start up, which seems to clean up the named_mutex if it is orphaned, or just do nothing if another, active, process has a lock - exactly the behaviour I require. However, is this platform independent, and a suitable technique?
Chard wrote:
Does calling named_mutex::remove() have consistent cross-platform behaviour?
No until the next Boost version. The UNIX behaviour will be the chosen behaviour: you can remove in-use named resources (named mutex, shared memory...)
On the Windows platform, I've found I can call named_mutex::remove() at start up, which seems to clean up the named_mutex if it is orphaned, or just do nothing if another, active, process has a lock - exactly the behaviour I require.
However, is this platform independent, and a suitable technique?
No, it's not portable. I think you should use file locks which are automatically unlocked when a process dies. However, take in care that to achieve portable file locks you have several restrictions that I think you can avoid in your case: http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess/synchronization_m... Best, Ion
Chard wrote:
Does calling named_mutex::remove() have consistent cross-platform be haviour?
No until the next Boost version. The UNIX behaviour will be the chosen behaviour: you can remove in-use named resources (named mutex, shared memory...)
I don't think the philosophy of boost should be influenced by the sick philosophy of the various UNIXs. Please do exploit modern operating system advantages if they are available.
peter_foelsche@agilent.com wrote:
Chard wrote:
Does calling named_mutex::remove() have consistent cross-platform be haviour?
No until the next Boost version. The UNIX behaviour will be the chosen behaviour: you can remove in-use named resources (named mutex, shared memory...)
I don't think the philosophy of boost should be influenced by the sick philosophy of the various UNIXs. Please do exploit modern operating system advantages if they are available.
My intention is just providing portability. "Create and unlink" named resources are usual in UNIX systems and I find them quite useful. And shared_memory is modeled after POSIX shared memory, that's why I wanted to provide a more homogeneous behaviour with the library. This portability was also requested by some users, but who knows, this might be a step in the wrong direction. Why do you think this unlink behaviour is worse than "file in use" error in windows? Best, Ion
My intention is just providing portability. "Create and unlink" named resources are usual in UNIX systems and I find them quite useful. And shared_memory is modeled after POSIX shared memory, that's why I wante d to provide a more homogeneous behaviour with the library. This portability was also requested by some users, but who knows, this migh t be a step in the wrong direction.
Why do you think this unlink behaviour is worse than "file in use" err or in windows?
I don't see any need to be able to remove mutexes which are in use. The sense of a named mutex is that only one mutex with a particular name can exist on a system. I still remember having to clean up named system objects (shared memory I think) by and then on SOLARIS. I don't like the idea of being able to confuse running processes. Somewhere in the SOLARIS documentation was a (quite ridiculous) message, which said (from memory): "Obligatory file locks are dangerous. Should a process hold a obligatory file lock on a system file, it can halt the entire system." Or: "Software updates should be done when the system is not much in use." Taking into account that a process usually crashes when the used executable or shared library file is being written to, I found this obvious acceptance of crashes not acceptable.
"Software updates should be done when the system is not much in use."
Taking into account that a process usually crashes when the used executable or shared library file is being written to, I found this obvious acceptance of crashes not acceptable.
Certainly, but that "attitude" is one of the particular people who wrote that solaris software, nothing more. Suggesting that it's somehow connected with unix delete behavior is simply silly. [Well designed package systems do not write to files to update them, they use rename to atomically move the new files into place -- due to the niceness of unix delete behavior, applications which have the old files open see no change.] -Miles p.s. pardon me for responding to such obvious flamebait... :-( -- Cat, n. A soft, indestructible automaton provided by nature to be kicked when things go wrong in the domestic circle.
"Ion Gaztañaga"
No, it's not portable. I think you should use file locks which are automatically unlocked when a process dies. However, take in care that to achieve portable file locks you have several restrictions that I think you can avoid in your case:
I've been trying an approach using file locks, and, as you say, the lock will be released should the process die. However, other issues arise as regards cleaning up the file used for the lock: who creates it, and who deletes it? Clearly, for the creation case, the file could be created if it didn't exist - though there's a potential race condition. The deletion case is also tricky: a process figures out it is the only one (by getting the exclusive file lock) and then deletes the file (under Windows this will 'mark' the file for deletion when the last handle is released, i.e. the file lock). Before the file 'truly' disappears, another process starts up and attempts to get a shared lock on the file...this will fail (certainly on Windows). I could just leave the file around, but it's not very clean. Is there another approach?
participants (4)
-
Chard -
Ion Gaztañaga -
Miles Bader -
peter_foelsche＠agilent.com