Let me analyze each possible exception case for boost::mutex:If not, then I would guess that it could be made exception safe by moving the destructor implementation into an explicit "close" method, and assert on it being called in the destructor.The implementation of boost::reverse_lock::~reverse_lock calls "lock" on the mutex retrieved from the provided lock. According to the documentation , "lock" can throw operation_not_permitted, resource_deadlock_would_occur or device_or_resource_busy exceptions. I don't see any catching of exceptions inside the destructor, and am therefore concerned about the exception safety of reverse_lock.Could someone please explain if reverse_lock is designed to be exception safe?
operation_not_permitted: if the thread does not have the privilege to perform the operation.
Couldn't we assume that if the thread was able to lock the mutex
before it will have the rights?
if the implementation detects that a deadlock would occur.
The current implementation is based on
The pthread_mutex_trylock() function will fail if:
The pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock() functions may fail if:
The pthread_mutex_lock() function may fail if:
The pthread_mutex_unlock() function may fail if:
These functions will not return an error code of [EINTR]."
Of course other model of Lockable could have other specificities.
The question is, what can we do on the destructor if lock()
throws? abort? ignore?
The current situation call terminate(). Ignoring the error seems not a good approach, or is it?