Roland Schwarz <roland.schwarz@chello.at> writes:
I'd like to know the rationale behind mutex concept requiring explicit locking signatures.
Are users of the library "allowed" to access them directly? If yes why? Isn't this redundant to locks?
I guess that by "locks" you mean scoped_lock. Howard has answered this before: there are use cases where you don't want strict scoped locking, so yes, users are "allowed" to access the lock member functions directly.
Not requiring them, but letting them be implementation defined will allow the implementor more freedom.
I don't think we need that freedom.
E.g. the requirement for these N2094 mutex concepts would make implementation of my proposed POD mutex variant impossible.
No it wouldn't. PODs can have member functions. You would have to wrap your pointer in a struct, but that wouldn't stop it being POD. Yes, you wouldn't be able to use a plain 0 as an initializer, but you could use a static zero-initialized instance of the struct.
E.g. the current boost mutex also does not need to make these explicit functions.
Which leads to the mess that is boost::detail::lock_ops, to enable code outside of the scoped_lock implementation (e.g. cond var implementation) to access these functions. People also use things like boost::shared_ptr<boost::mutex::scoped_lock> to get round the restrictions. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk