Clarify GetExclusiveOwner() semantics

It is inherently unreliable unless the mutex is held.
Contention reports may err if the mutex has already been, or is
about to be, released.

Fixing this would require including exclusive_owner_ in the atomic
operation part of lock/unlock operations, which would require us to rely
on wider atomic operations on the fast path. So just document it better.

Bug: 377068860
Test: Treehugger
Change-Id: Id2be3dca573656e7aa10cf975f9a6c9275cd3541

2 files changed, 2 insertions, 1 deletions

diff --git a/runtime/base/mutex.cc b/runtime/base/mutex.cc
index 0abe9667f8..26a665bd41 100644
--- a/runtime/base/mutex.cc
+++ b/runtime/base/mutex.cc
@@ -463,6 +463,7 @@ void Mutex::ExclusiveLock(Thread* self) {
         done = state_and_contenders_.CompareAndSetWeakAcquire(cur_state, cur_state | kHeldMask);
       } else {
         // Failed to acquire, hang up.
+        // We don't hold the mutex: GetExclusiveOwnerTid() is usually, but not always, correct.
         ScopedContentionRecorder scr(this, SafeGetTid(self), GetExclusiveOwnerTid());
         // Empirically, it appears important to spin again each time through the loop; if we
         // bother to go to sleep and wake up, we should be fairly persistent in trying for the
diff --git a/runtime/base/mutex.h b/runtime/base/mutex.h
index e3d89e7449..9185f79ab7 100644
--- a/runtime/base/mutex.h
+++ b/runtime/base/mutex.h
@@ -394,7 +394,7 @@ class EXPORT SHARED_LOCKABLE ReaderWriterMutex : public BaseMutex {
 
   // Id associated with exclusive owner. No memory ordering semantics if called from a thread other
   // than the owner. Returns 0 if the lock is not held. Returns either 0 or -1 if it is held by
-  // one or more readers.
+  // one or more readers. Not reliable unless the mutex is held.
   pid_t GetExclusiveOwnerTid() const;
 
   void Dump(std::ostream& os) const override;