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()
    {}

};

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

> 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

-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk

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