Re: [boost] [thread] Question about MT API C++0X N2094

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