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. If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided. If a thread attempts to relock a mutex that it has already locked, an error shall be returned. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned. .... For example, deadlocking on a double-lock is explicitly allowed behavior in order to avoid requiring more overhead in the basic mechanism than is absolutely necessary. (More "friendly" mutexes that detect deadlock or that allow multiple locking by the same thread are easily constructed by the user via the other mechanisms provided. For example, pthread_self() can be used to record mutex ownership.) Implementations might also choose to provide such extended features as options via special mutex attributes. ...." regards, alexander. -- Unix(R) and UnixWare(R) are registered trademarks of The Open Group in the United States and other countries. OTOH, "OPENSERVER" is the ABANDONED (dead) trademark in the United States. In other news, all SCO operating systems (if any/and etc.) are dead in other countries and the United States. Please visit <http://www.sco.de>. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
