[Boost-users] [interprocess] named mutex clean up
Chard
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?
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ion Gaztañaga
> 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:
Best,
Ion
peter_f...@agilent.com
> > 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.
Ion Gaztañaga
>> 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
peter_f...@agilent.com
> 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.
Chard
news:49DBD7B2...@gmail.com...
>
> 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?
Miles Bader
> "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.