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.