Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-30 11:29:56


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk