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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
