Roland Schwarz <roland.schwarz@chello.at> 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 mutex. 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 -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk