Re: [boost] Re: [boost::thread] locks, exceptions and assertions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-07-22 09:03:21

Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> It's not that simple. Whether something is a programming error is
>> determined by the library's specification, not vice versa. In other
>> words, under the current specification, re-locking a locked lock :-)
>> is not an error, as it is well defined. It is not a just an
>> implementation question of using assert or throw, it is a design
>> question.
>
>
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_lock.html
>
> "....
>  If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall
>  not be provided. Attempting to relock the mutex causes deadlock. If
>  a thread attempts to unlock a mutex that it has not locked or a
>  mutex which is unlocked, undefined behavior results.

Double calls to pthread_mutex_lock are the equivalent of doing

scoped_lock l1(m);
scoped_lock l2(m);

This is already undefined behavior when m is boost::mutex according to the
mutex requirements; m is not required to check for deadlocks. We are
discussing the

scoped_lock l1(m);
l1.lock();

case. Since l1 is required to know whether it's been locked or not (it has a
public locked() query) it can easily check.