From 61fdd3e2bee1ea0f517ff0bfe16f3816decab99a Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 4 May 2020 19:17:58 +0200 Subject: expand comment on default mutex behavior --- src/libstd/sys/unix/mutex.rs | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'src/libstd/sys') diff --git a/src/libstd/sys/unix/mutex.rs b/src/libstd/sys/unix/mutex.rs index 103d87e3d2f..185615d01dd 100644 --- a/src/libstd/sys/unix/mutex.rs +++ b/src/libstd/sys/unix/mutex.rs @@ -28,14 +28,18 @@ impl Mutex { // // A pthread mutex initialized with PTHREAD_MUTEX_INITIALIZER will have // a type of PTHREAD_MUTEX_DEFAULT, which has undefined behavior if you - // try to re-lock it from the same thread when you already hold a lock. + // try to re-lock it from the same thread when you already hold a lock + // (https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html). // // In practice, glibc takes advantage of this undefined behavior to // implement hardware lock elision, which uses hardware transactional - // memory to avoid acquiring the lock. While a transaction is in + // memory to avoid acquiring the lock. + // This is the case even if PTHREAD_MUTEX_DEFAULT == PTHREAD_MUTEX_NORMAL + // (https://github.com/rust-lang/rust/issues/33770#issuecomment-220847521). + // As a consequence, while a transaction is in // progress, the lock appears to be unlocked. This isn't a problem for // other threads since the transactional memory will abort if a conflict - // is detected, however no abort is generated if re-locking from the + // is detected, however no abort is generated when re-locking from the // same thread. // // Since locking the same mutex twice will result in two aliasing &mut -- cgit 1.4.1-3-g733a5