Unnecessary locking in pthread mutex drop?

[CXWorks]

Hi, thanks for your time. I noticed that in the drop implementation of pthread_mutex lock, the std lib tries to get the lock and then unlock it before destory the lock.

rust/library/std/src/sys/sync/mutex/pthread.rs

Lines 55 to 64 in 414482f

	// We're not allowed to pthread_mutex_destroy a locked mutex,
	// so check first if it's unlocked.
	if unsafe { pal.as_ref().try_lock() } {
	unsafe { pal.as_ref().unlock() };
	drop(pal)
	} else {
	// The mutex is locked. This happens if a MutexGuard is leaked.
	// In this case, we just leak the Mutex too.
	forget(pal)
	}

Here (in safe Rust), since all the MutexGuard should be borrowed from this Mutex, is it impossible to have a locked status of the Mutex in its drop, why do we need to check and unlock here? Only to be compatible with potential unsafe Rust?

[theemathas]

std::mem::forget is safe. Safe code might call forget on the MutexGuard, leaving the Mutex locked. See https://doc.rust-lang.org/nomicon/leaking.html

[joboet]

Yes, this is unfortunately unavoidable with pthreads...