Well the destructor of the scoped_lock calls unlock, or am I missing something?
Sorry if this question has a obvious answer. It is sure that the destructors will be called when a process is killed?
Sorry, I explained incorrectly. There is nothing obvious about these complex system programming issues. You can translate into exceptions most of the "problems" that will cause a process to terminate. Access violation, division by zero, stack overflow, etc. This way you can make sure the destructors are called thanks to stack unwinding. This is not a silver bullet but you will have some sort of cover. On top of that, if you add a handler for memory allocation error, you have yourself a reasonable guarantee that you will fail gracefully. Of course when the process is terminated by the OS, nothing is called. From the kernel point of view, a process is just a structure with handles referencing kernel objects. When it says... "DIE !", all threads cease to be scheduled, virtual memory gets unmapped and everything created by the process is destroyed, except, as you noticed, shared objects such as a named mutex. Since your threads are no longer scheduled, no chance that the code of your destructor is run. Dang! It's not even referenced by the VMM anymore! AAAaahhhhh. Tar pit. If the process terminates by itself, functions registered with atexit and destructors of static variables are called. Now the question is against which kind of process termination do you wish to protect yourself? On which platform? If you wish to protect against the user terminating your process there's not much you can do as Ion explained. You can remove termination rights, but again, if the user has got root/administrator privileges it can just sudo his way to your demise. Kind regards. -- EA