Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-31 16:28:22

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> Anthony Williams wrote:
>> I think it is worth pursuing any and all avenues of finding a mutex which can
>> safely be used with either static or dynamic storage duration.
> Did you found time to try out my POD mutex?
> I would be very interested if you could comment on it.

Not yet, sorry.

>> This was predicated on the idea that the various library
>> implementers each knew platform- and compiler- specific ways of doing this, so
>> we should specify the most user-friendly interface.
> Not sure what this exactly means, can you exemplify?

std::mutex global;

void f()
    static std::mutex local_static;
    std::mutex automatic;
    std::mutex* dynamic=new std::mutex;

class X
    std::mutex class_data_member;



X global_as_member;

void g()
    static X local_static_as_member;
    X automatic_as_member;
    X* dynamic_as_member=new X;

in no case is an initializer required. In all cases it should "just work",
which requires platform-specific code.

>> Therefore, I think that boost should try and provide this interface as far as
>> we are able. POD mutexes is one way. Named mutexes is another.
> Which kind of named are you talking about here?
> I do not believe opsys-named is the correct way to go.

opsys-named is just one way of implementing named mutexes. Your global map is

> If you think the simplest interface is doing away with the mutices
> altogether I am with you.
> scoped_lock lk(&foo); should be enough. Implementing this efficiently
> however is another story.

No, that's not what I meant. The proposal(s) before the Standards committee
are for an explicit mutex type. By "simplest interface" I meant not requiring
any explicit initialization under any circumstances.


Anthony Williams
Software Developer
Just Software Solutions Ltd

Boost list run by bdawes at, gregod at, cpdaniel at, john at