From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-30 05:56:07
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> class foo
> } afoo;
> lock lk(&afoo);
> where &afoo is the process - unique equivalent
> of a name for a mutex. Unfortunately a mutex
> is an object that carries state, and foo isn't
> prepared to store this state.
> The problem is that this takes too much steps
> at a time. Bringing the mutex again into play
> to store the state one could say:
> mutex& m1 = named_mutex::open(&afoo);
> which will give back an unique mutex.
> At another place, only knowing afoo's address
> we could say:
> mutex& m2 = named_mutex::open(&afoo);
> and this will hand out an equivalent mutex.
> Normally you would need to create a process wide
> visible mutex to accomplish the same effect,
> altough knowing an unique identifier, as is the
> address, would be sufficient.
Windows named mutexes do give you exactly this functionality, though as they
are kernel objects you don't get the "fast path" options of a roll-your-own
If the name for your mutex includes the process ID and &afoo, then Windows
will give you a distinct mutex for each distinct foo object. You need the
process ID, so you don't get a clash with mutexes in other processes, since
named mutexes are system-global.
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk