Anthony Williams wrote:
In practical terms, the only problems with your scheme are:
* Ensuring the that these "named" mutexes are correctly destroyed at process termination, if people don't "close" the mutex. Maybe not an issue.
This is the same as forgetting a system opened object to be closed. Don't know if named system mutices will get theit refernce decremented when the process exists though.
* Contention on the map. Ideally we don't want to have any contention for unrelated mutexes. Chris Thomasson has suggested using a global lock-free hashmap for this sort of thing.
Yes, of course. I just wanted to present and discuss the interface. Altough the contention is possibly not too high anyways, since one can expect shared objects creation frequency much lower than access frequency. And in my proposed scheme contention only occurs during creation. This would be different if creating a lock in the following manner: class lock { public: lock(const void* addr) { myaddr = addr; pmutex = &named_mutex::open(addr); } ~lock() { named_mutex::close(myaddr); } .... private: mutex* pmutex; const void* myaddr; }; This scheme indeed would give high contention, and only could be realized by means of a very fast concurrent hash map. Roland