![]() |
Boost : |
From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-01 08:57:01
Roland Schwarz <roland.schwarz_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk