If a lock is poisoned, it means some thread having acquired it has
panic!ked. Now, the important thing to know, here, is what that thread was doing with the acquired lock:
either it had acquired the lock for read-access only,
in which case the data guarded by the
Mutex is still in the state it was when that thread acquired the lock (and succeeded), that is, a safe state.
In that case, instead of using
.lock().unwrap(), it is safe to use
or the thread may have been mutating the data guarded by the
panic! may then have occurred in the middle of a critical section, thus having potentially not reached a “re-establish the invariant” clean-up phase at the end of such section. The data guarded may therefore no longer have the invariant it is supposed to have, which may lead to logic bugs; if
unsafe is used somewhere, these logic bugs may very likely compromise memory safety.
Thus the only sane thing to do here is to either
panic! (e.g., with
.lock().unwrap()), or have a way to start from scratch: wrap a new value in a new
Mutex, and ensure other threads use that new
Long story short, if there were to be such a clear distinction between read-access locks, and write-access locks, then
RwLock should be used instead (of
Mutex); and in that case, a poisoned lock can only come from the latter “almost-unrecoverable” case where
.unwrap() is not only acceptable, but advised.
So you might as well
panic!() on poisoned
Mutexes, using something like
.lock().expect("Mutex was poisoned") so that users of the library can get a more descriptive
panic! message in that case