C#筆記 – 線程及異步（四）線程同步構造

FCL中的混合構造

• 一個簡單的混合鎖
  • 由用戶模式構造操作和內核模式操作共同構建

  •   internal sealed class HybridLock : IDisposable
      {
          int m_Waiter = 0; //基元用戶模式構造
          AutoResetEvent m_WaitLocks = new AutoResetEvent(false); //基元內核模式構造
      
          public void Enter()
          {
      
              if(Interlocked.Increment(ref m_Waiter) == 1)
              {
                  //以前有0個線程正在等待這個鎖，鎖可以自由使用
                  return;
              }
      
              //否則等待
              m_WaitLocks.WaitOne(); 
              //WaitOne返回後得到鎖
          }
      
          public void Leave()
          {
              if(Interlocked.Decrement(ref m_Waiter) == 0)
              {
                  //釋放後沒有其他線程正在等待
                  return;
              }
      
              //否則喚醒其中一個正在等待的線程
              m_WaitLocks.Set();
          }
      
          public void Dispose()
          {
              m_WaitLocks.Dispose();
          }
      }

ManualResetEventSlim類和SemaphoreSlim類

• 這兩個構造的工作方式和對應的內核模式構造完全一致，只是它們都在用戶模式中「自旋」

• 而且只有到第一次競爭發生時，才創建內核模式的構造

• ManualResetEventSlim

  •   namespace System.Threading
      {
          public class ManualResetEventSlim : IDisposable
          {
              public ManualResetEventSlim(bool initialState);
              public ManualResetEventSlim(bool initialState, int spinCount);
              public bool IsSet { get; }
              public int SpinCount { get; }
              [NullableAttribute(1)]
              public WaitHandle WaitHandle { get; }
              public void Dispose();
              public void Reset();
              public void Set();
              public void Wait();
              public bool Wait(int millisecondsTimeout);
              public bool Wait(int millisecondsTimeout, CancellationToken cancellationToken);
              public void Wait(CancellationToken cancellationToken);
              public bool Wait(TimeSpan timeout);
              public bool Wait(TimeSpan timeout, CancellationToken cancellationToken);
              protected virtual void Dispose(bool disposing);
          }
      }

• SemaphoreSlim

  •   namespace System.Threading
      {
          [NullableAttribute(0)]
          [NullableContextAttribute(1)]
          public class SemaphoreSlim : IDisposable
          {
              public SemaphoreSlim(int initialCount);
              public SemaphoreSlim(int initialCount, int maxCount);
              public WaitHandle AvailableWaitHandle { get; }
              public int CurrentCount { get; }
              public void Dispose();
              public int Release();
              public int Release(int releaseCount);
              public void Wait();
              public bool Wait(int millisecondsTimeout);
              public bool Wait(int millisecondsTimeout, CancellationToken cancellationToken);
              public bool Wait(TimeSpan timeout);
              public bool Wait(TimeSpan timeout, CancellationToken cancellationToken);
              public void Wait(CancellationToken cancellationToken);
              public Task WaitAsync();
              public Task<bool> WaitAsync(int millisecondsTimeout);
              public Task<bool> WaitAsync(int millisecondsTimeout, CancellationToken cancellationToken);
              public Task WaitAsync(CancellationToken cancellationToken);
              public Task<bool> WaitAsync(TimeSpan timeout);
              public Task<bool> WaitAsync(TimeSpan timeout, CancellationToken cancellationToken);
              protected virtual void Dispose(bool disposing);
          }
      }

Monitor類和同步塊

• 提供了自旋、線程所有權和遞歸的互斥鎖

• 堆中的每個對象都可關聯一個「同步塊」

  • 同步塊為內核對象、擁有線程（owning thread）ID、遞歸計數和等待線程計數提供了相應的字段
  • Monitor是靜態類，它的方法接受對任何堆對象的引用，這些方法對指定對象的同步塊中的字段進行操作

    •   namespace System.Threading
        {
            [NullableAttribute(0)]
            [NullableContextAttribute(1)]
            public static class Monitor
            {
                public static long LockContentionCount { get; }
                       
                public static void Enter(object obj);
                public static void Enter(object obj, ref bool lockTaken);
                public static void Exit(object obj);
                public static bool IsEntered(object obj);
                public static void Pulse(object obj);
                public static void PulseAll(object obj);
                public static bool TryEnter(object obj);
                public static void TryEnter(object obj, ref bool lockTaken);
                public static void TryEnter(object obj, int millisecondsTimeout, ref bool lockTaken);
                public static bool TryEnter(object obj, TimeSpan timeout);
                public static void TryEnter(object obj, TimeSpan timeout, ref bool lockTaken);
                public static bool TryEnter(object obj, int millisecondsTimeout);
                public static bool Wait(object obj, TimeSpan timeout, bool exitContext);
                public static bool Wait(object obj);
                public static bool Wait(object obj, int millisecondsTimeout);
                public static bool Wait(object obj, int millisecondsTimeout, bool exitContext);
                public static bool Wait(object obj, TimeSpan timeout);
            }
        }

• 對象在堆中實際關聯的不是同步塊，而是「同步塊索引」

  • 這是因為大多數對象的同步塊的使用率都很低，因為為了節省內存，不會為每個對象都關聯一個同步塊
  • 實際上，CLR初始化是，在堆中分配一個「同步塊數組」
    • 一個對象構造時，同步塊索引初始化為-1，表明不引用任何同步塊
      • 然後調用Monitor.Enter時，CLR在數組中找到一個空白同步塊，並設置對象的「同步塊索引」，讓它引用該同步塊
      • 同步塊和對象是「動態關聯」的
      • 調用Exit時，會檢查是否有其他任何線程正在等待使用對象的同步塊，如果沒有，Exit會將對象的同步塊索引設回-1
        • 不再被該對象引用的同步塊可在將來與其他對象關聯

• 作為靜態類的Monitor，存在很多問題

  • 變量能引用一個代理對象（派生自MarshalByRefObject）。調用Monitor的方法時，傳遞對代理對象的引用，鎖定的是代理對象而不是代理引用的實際對象
  • 線程調用Monitor.Enter，傳遞以「AppDomain中立」方式加載的類型對象的引用，線程就會跨越進程中所有的AppDomain，在那個類型上獲取鎖，破壞AppDomain的隔離性
  • 由於字符串可以留用，可能使兩個獨立的代碼段獲取對內存的一個string對象的引用；將這個引用傳給Monitor方法，會導致兩個獨立的代碼段「同步」執行
    • 另外，跨越AppDomain傳遞字符串時，雖然字符串本身不可修改，但是字符串關聯的同步塊索引是可以修改的
    • 使不同AppDomain中的線程在不知情的情況下開始同步
  • Monitor要求一個object，會導致值類型裝箱，造成在已裝箱對象上獲取鎖。因此，每次調用Monitor.Enter都會在一個完全不同的對象上獲取鎖，無法實現線程同步
  • MethodImplOptions.Synchronized特性會造成JIT編譯器用Monitor.Enter和Exit包圍本機代碼
    • 如果是實例方法，會將this傳給Enter和Exit，鎖定隱式公共的鎖
    • 如果是靜態方法，會把類型的類型對象引用傳給Enter和Exit，造成「AppDomain中立」的類型被鎖定
    • 建議永遠不要使用該特性
  • 調用類型的類構造器時，CLR要獲取類型對象上的一個鎖，確保只有一個線程初始化類型對象及其靜態字段
    • 該類型可能用AppDomain中立方式加載，會出問題

ReaderWriterLockSlim類

• 如果所有線程都以只讀的方式訪問數據，就沒有必要阻塞並應該允許并發
• 如果一個線程希望修改數據，這個線程就需要對數據的獨占式訪問
• ReaderWriterLockSlim的具體構造邏輯
  • 一個線程向數據寫入時，請求訪問的其他所有線程都被阻塞
  • 一個線程從數據讀取時，請求讀取的其他線程允許繼續執行，但請求寫入的線程仍被阻塞
  • 向線程寫入的線程結束後，要麼解除一個寫入線程（writer）的阻塞；要麼解除所有讀取線程（reader）的阻塞
  • 從數據讀取的所有線程結束後，一個writer線程被解除阻塞

CountdownEvent類

• 使用了一個ManualResetEventSlim對象
• 這個構造阻塞一個線程，直到它的內部計數器為0（與Semaphore構造相反）
• 一旦其計數變成0，就不能再更改了

線程小結

• 盡量不要阻塞任何線程
  • 執行異步操作，將數據從一個線程交給另一個線程時，應避免多個線程同時訪問數據
  • 實在不行，盡量使用volatile和Interlocked方法
    • 速度很快
    • 絕不阻塞線程
• 阻塞線程的場景
  • 線程模型簡單
  • 線程有專門用途
• 如果一定要阻塞線程，為了同步在不同AppDomain/進程中運行的線程，使用內核對象構造
  • 要在一系列操作中原子性地操縱狀態，使用帶有私有字段的Monitor類
    • 或使用reader-writer鎖代替Monitor
• 避免使用遞歸鎖
• 不要在finally塊中釋放鎖
• 對於計算限制的工作（如計時），可以使用Task

并發集合類

• FCL自帶4個線程安全的集合類，在System.Collections.Concurrent命名空間中
  • ConcurrentQueue
  • ConcurrentStack
  • ConcurrentDictionary
  • ConcurrentBag
    • 無序數據項集合，可以重複
• 上述所有集合類都是「非阻塞」的，如果一個線程試圖提取一個不存在的元素，線程會立即返回，不會阻塞
• 所有并發集合類都提供了GetEnumerator方法
  • 該方法獲取集合內容的一個快照，並從這個快照中返回元素
  • 實際集合的內容可能在使用快照枚舉時發生改變
    • ConcurrentDictionary的GetEnumerator方法不獲取內容快照，因此，在枚舉字典期間，字典內容可能改變
• Count屬性返回的是查詢時集合中的元素數量，如果其他線程同時正在集合中增刪元素，可能導致計數不準確
• 除了ConcurrentDictionary外的三個并發集合類，都實現了IProducerConsumerCollection接口
  • 該接口可把集合轉變成一個阻塞集合

參考書目

• 《CLR via C#》（第4版） Jeffrey Richter