Cache TID in TLS on Linux

Author: Azoy

stdlib/public/SwiftShims/swift/shims/SynchronizationShims.h

@@ -24,7 +24,8 @@
 #define SWIFT_FUTEX_WAITERS FUTEX_WAITERS
 
 static inline __swift_uint32_t _swift_stdlib_gettid() {
-  return syscall(SYS_gettid);
+  static __thread tid = syscall(SYS_gettid);
+  return tid;
 }
 
 static inline __swift_bool _swift_stdlib_wait(__swift_uint32_t *lock) {

stdlib/public/Synchronization/Cell.swift

@@ -30,4 +30,11 @@ internal struct _Cell<Value: ~Copyable>: ~Copyable {
   init(_ initialValue: consuming Value) {
     Builtin.initialize(initialValue, rawAddress)
   }
+
+  @available(SwiftStdlib 6.0, *)
+  @_alwaysEmitIntoClient
+  @inlinable
+  deinit {
+    Builtin.destroy(Value.self, rawAddress)
+  }
 }

stdlib/public/Synchronization/Mutex/LinuxImpl.swift

@@ -44,7 +44,7 @@ internal struct _MutexHandle: ~Copyable {
   @available(SwiftStdlib 6.0, *)
   @usableFromInline
   borrowing func lock() {
-    // TODO: Is it worth caching this value in TLS?
+    // Note: This is being TLS cached.
     let selfId = _swift_stdlib_gettid()
 
     // Note: We could probably merge this cas into a do/while style loop, but we
@@ -101,6 +101,8 @@ internal struct _MutexHandle: ~Copyable {
   borrowing func tryLock() -> Bool {
     storage.compareExchange(
       expected: 0,
+
+      // Note: This is being TLS cached.
       desired: _swift_stdlib_gettid(),
       successOrdering: .acquiring,
       failureOrdering: .relaxed
@@ -110,7 +112,7 @@ internal struct _MutexHandle: ~Copyable {
   @available(SwiftStdlib 6.0, *)
   @usableFromInline
   borrowing func unlock() {
-    // TODO: Is it worth caching this value in TLS?
+    // Note: This is being TLS cached.
     let selfId = _swift_stdlib_gettid()
 
     // Attempt to release the lock. We can only atomically release the lock in

stdlib/public/Synchronization/Mutex/Mutex.swift

@@ -10,8 +10,6 @@
 //
 //===----------------------------------------------------------------------===//
 
-import Builtin
-
 /// A synchronization primitive that protects shared mutable state via
 /// mutual exclusion.
 ///

stdlib/public/Synchronization/Mutex/WasmImpl.swift

@@ -10,6 +10,9 @@
 //
 //===----------------------------------------------------------------------===//
 
+// Note: All atomic accesses on WASM are sequentially consistent regardless of
+// what ordering we tell LLVM to use.
+
 @_extern(c, "llvm.wasm32.memory.atomic.wait32")
 func _swift_stdlib_wait(
   on: UnsafePointer<UInt32>,
@@ -37,6 +40,18 @@ extension Atomic where Value == UInt32 {
   }
 }
 
+@available(SwiftStdlib 6.0, *)
+extension _MutexHandle {
+  @available(SwiftStdlib 6.0, *)
+  @frozen
+  @usableFromInline
+  internal enum State: UInt32, AtomicRepresentable {
+    case unlocked
+    case locked
+    case contended
+  }
+}
+
 @available(SwiftStdlib 6.0, *)
 @frozen
 @usableFromInline
@@ -75,7 +90,11 @@ internal struct _MutexHandle: ~Copyable {
       // If we're not already contended, go ahead and transition the mutex state
       // into being contended. If when we do this that the value stored there
       // was unlocked, then we know we unintentionally acquired the lock. A
-      // weird quirk is that 
+      // weird quirk that occurs if this happens is that we go directly from
+      // .unlocked -> .contended when in fact the lock may not be contended.
+      // We may be able to do another atomic access and change it to .locked if
+      // acquired it, but it may cause more problems than just potentially
+      // calling wake with no waiters.
       if state != .contended, storage.exchange(
         .contended,
         ordering: .acquiring
@@ -130,14 +149,3 @@ internal struct _MutexHandle: ~Copyable {
     // Unlocked!
   }
 }
-
-extension _MutexHandle {
-  @available(SwiftStdlib 6.0, *)
-  @frozen
-  @usableFromInline
-  internal enum State: UInt32, AtomicRepresentable {
-    case unlocked
-    case locked
-    case contended
-  }
-}