Re: [boost] [thread] A simply static initializeable mutex and a named one

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
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