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?
static std::mutex local_static;
std::mutex* dynamic=new std::mutex;
static X local_static_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 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