Roland Schwarz <roland.schwarz@chello.at> 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