Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-25 14:48:36

On Aug 25, 2007, at 2:11 PM, Peter Dimov wrote:

> I'll wait for this hypothetical client to appear.

So if we were targeting boost, or even TR2, we would have this  
luxury.  We're not and we don't.  We need to get it right the first  
time.  Failing strong consensus of what is "right", we're going to get  
the current boost::condition.  I'm not even positive how to interpret  
the spec for boost::condition: either mutex-only, or generalized, but  
definitely not both since it isn't templated.

> To try to provide a summary: we have three conditions on the table:  
> (1)
> unchecked, (2) possibly checked, and (3) checked. Your original  
> design has
> (3) as default, (1) when the mutex argument is wrapped by  
> unchecked<>. The
> direction you now seem to be exploring is (1) by default, (3) as an  
> option,
> which I regard as a regression. I suggest (2) by default, with (3)  
> as an
> option, but only if there proves to be demand.

Nice summary.  I'm very opposed to (2).  It says:

Here's a constructor and the only difference between it and the other  
constructor (or other form of the same constructor) is that it adds a  
bunch of undefined behavior.

That just can't be a good thing to put into a standard.

> Regardless of what is chosen, I maintain that the three conditions  
> must
> syntactically have the same interface, that is, it must be possible  
> to pass
> a mutex even to (1). It would be painful to switch between them if  
> they do
> not.

I've actually been doing this switching a lot recently in my prototype  
and associated test code.  It isn't that painful.  But I agree it  
would be nice to not have to do it at all.  If we only manage to  
standardize (1), then justifying a constructor that looks different  
but has no difference in behavior is hard to justify.  If we manage to  
standardize both (1) and (3), then it becomes much easier to justify  
such a constructor.

I'm strictly looking at this from the client's point of view.  I'm the  
client.  I know what I want, and I want to be able to pick something  
and know what it does.  I don't want to be stuck with something that  
maybe does something, and maybe not.  It's like buying something with  
absolutely no warranty.

-Howard