Re: [boost] Comments about N2320

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-10-30 20:01:43

On Oct 30, 2007, at 3:43 PM, Yuval Ronen wrote:

>>> * If C++0x is going to have lambda support (is it?), then maybe the
>>> not-accepting-predicate overloads of condition::wait are no longer
>>> needed, and can be removed? I think the major reason why people use
>>> that
>>> overload is because they are too lazy to write a functor. With core
>>> support for lambda, it's a breeze. This will solve the other problem
>>> (mentioned in some other thread in this ML) about absolute vs.
>>> relative
>>> times.
>>
>> I would be very hesitant to force one programming style over
>> another.  Sometimes, for whatever reasons, one might really need an
>> explicit loop (say to handle more complex flow control than just
>> while (!pred) cv.wait(lk)).
>
> Is there any known use case for that? The common practice, and as  
> far as
> I remember, it's also defined by POSIX, that *all* calls to wait  
> must be
> like while (!pred) cv.wait(), so there is no other way. Is it?

I was thinking about "embellished" while loops.  Maybe something like:

while (!pred())
{
     cv.timed_wait(lk, std::get_system_time() + std::milliseconds(100));
     bool is_canceled = true;
     if (std::atomic_compare_and_swap(&cancel, &is_canceled, false))
     {
         cv2.notify_one();
         while (!exceptional_pred())
             cv.wait(lk);
         throw thread_canceled();
     }
}

All of this could probably be packed into a predicate.  But it might  
be inconvenient.  Sometimes it is easier to just write your own loop.

>>> 2. Make sizeof(unique_lock) smaller - no need for bool owns.
>>
>> Even if we remove defer_lock, unique_lock will still need the
>> internal bool to support try and timed locks.  This functionality
>> still retains a reference to the mutex even if the try/timed lock
>> fails (so that further action with the mutex can be easily taken).
>
> This is something I don't understand. Why should the lock retain a
> reference to the mutex even if the try/timed lock fails?

Because if the try_lock fails, I might want to take some corrective  
action and then do a blocking lock() on the mutex.  If the lock has  
retained the reference to the mutex, I don't have to store that  
reference elsewhere "just in case" the try_lock fails.

>>> 3. Make unique_lock more similar to unique_ptr, which makes it more
>>> intuitive.
>>> 4. Make std::lock simpler in the way that it doesn't need to accept
>>> locks, only mutexes.
>>
>> std::lock isn't further complicated by accepting both mutexes and
>> locks.  It accepts anything that supports lock(), try_lock() and
>> unlock().  To disallow locks, we would have to make std::lock more
>> complicated by detecting lock template arguments and then actively
>> disabling them.  I see no motivation to add this complication.
>
> Oh no, I wasn't suggesting something like that at all. By "make
> std::lock simpler" I meant simpler in our heads. Make our thinking  
> of it
> simpler. Thinking about it (and documenting it) as something that  
> deals
> with mutexes is simpler than if it was dealing with both mutexes  
> and locks.

The current spec just says:

Each template parameter type must supply the following member  
functions with semantics corresponding to the Mutex concept, except  
that try_lock is allowed to throw an exception [Note: The unique_lock  
class template meets these requirements when suitable instantiated. -- 
end note]

void lock();
bool try_lock();
void unlock();

I suppose we could remove the note.  But I really don't think that  
simplifies anything.

>>> In general it seems you paid a lot of attention to being able to
>>> pass a
>>> lock instead of a mutex wherever possible. I think it's  
>>> absolutely not
>>> necessary. It's an undue complication.
>>
>> Actually I tried to pay attention to what the minimal requirements
>> were on template parameters.  It just turned out that some generic
>> code would accept either locks or mutexes.
>
> But you made the effort of mentioning it several times in the  
> document.
> That implies importance. My claim is that there is no importance to  
> it,
> because there's no use for it, even if it happens that we named
> unique_lock::lock the same way we named mutex::lock. We could've have
> named them differently. And while I'm thinking of it, why is there a
> lock() method for unique_lock anyway? Isn't it unnecessary?

The original answer is because that's the way boost::scoped_lock  
specified its API.  After further study and experience, I find myself  
in complete agreement with the boost API in this regard, at least for  
unique_lock.  I think the member lock() functions on unique_lock are  
quite convenient.  That being said, please see lock_guard in N2447  
which both lacks the defer_lock functionality, and lacks member lock,  
try_lock and unlock functions.  It also lacks the internal bool you  
would like to get rid of.  I think we may already have what you're  
looking for, just under a different name.

-Howard