機制 linux Linux訊號量機制分析

說明：

kernel版本：4.14

arm64處理器，contex-a53，雙核

使用工具：source insight 3.5， visio

本文將分析訊號量與讀寫訊號量的機制，開始吧。

訊號量的實現很簡單，先看一下資料結構：

struct semaphore ;struct semaphore_waiter ;

在保護臨界區的時候，無法進行優先順序反轉的處理；

系統無法對其進行跟蹤斷言處理，比如死鎖檢測等；

訊號量的除錯變得更加麻煩；

因此，在mutex能滿足要求的情況下，優先使用mutex。

訊號量提供了多種不同的訊號量獲取的介面，介紹如下：

/* 未獲取訊號量時，程序輕度睡眠：task_interruptible */int down_interruptible(struct semaphore *sem)/* 未獲取到訊號量時，程序中度睡眠：task_killable */int down_killable(struct semaphore *sem)/* 非等待的方式去獲取訊號量 */int down_trylock(struct semaphore *sem)/* 獲取訊號量，並指定等待時間 */int down_timeout(struct semaphore *sem, long timeout)

讀寫訊號量的資料結構與訊號量的結構比較相似：

在獲取釋放讀鎖和寫鎖的全過程中，count值伴隨著上述這幾個巨集定義的加減操作，用於標識不同的狀態，可以羅列如下：

0xffff000x = rwsem_active_write_bias + (x - 1)* rwsem_active_read_bias，表示有乙個寫者在嘗試獲取鎖，活躍的讀者和正在申請讀鎖的讀者總共有x-1個；

0xffff0001：分為以下幾種情況：

0xffff0001 = rwsem_active_write_bias，有乙個活躍的寫者，或者寫者正在嘗試獲取鎖，沒有讀者干擾；

0xffff0001 = rwsem_active_read_bias + rwsem_waiting_bias，有個寫者正在睡眠等待，還有乙個活躍或嘗試獲取鎖的讀者；

總結一下：讀者獲取鎖的時候，如果沒有寫者持有，那就可以支援多個讀者直接獲取；而如果此時寫者持有了鎖，讀者獲取失敗，它將把自己新增到等待列表中，(這個等待列表中可能已經存放了其他來獲取鎖的讀者或者寫者)，在將讀者真正睡眠等待前，還會再一次判斷此時是否有寫者釋放了該鎖，釋放了的話，那就需要對睡眠等待在該鎖的任務進行喚醒操作了

總結寫者獲取鎖時，只要鎖被其他讀者或者寫者持有了，則獲取鎖失敗，然後進行失敗情況處理。在失敗情況下，它本身會嘗試進行optimistic spin去嘗試獲取鎖，如果獲取成功了，那就是皆大歡喜了，否則還是需要進入慢速路徑。慢速路徑中去判斷等待列表中是否有任務在睡眠等待，並且會再次嘗試去檢視是否已經有寫者釋放了鎖，寫者釋放了鎖，並且只有讀者在睡眠等待，那麼此時應該優先讓這些先等待的任務喚醒

理解讀寫訊號量有幾個關鍵點：

讀寫訊號量的特性可以與讀寫自旋鎖進行模擬(讀者與讀者併發、讀者與寫者互斥、寫者與寫者互斥)，區別在於讀寫訊號量可能會發生睡眠，進而帶來程序切換的開銷；

為了優化讀寫訊號量的效能，引入了mcs鎖機制，進一步減少切換開銷。第乙個寫者獲取了鎖後，第二個寫者去獲取時自旋等待，而讀者去獲取時則會進入睡眠；

讀寫訊號量的count值很關鍵，代表著讀寫訊號量不同狀態的切換，因此也決定了執行流程；

讀者或寫者釋放鎖的時候，去喚醒等待列表中的任務，需要分情況處理。等待列表中可能存放的是讀者與寫者的組合，如果第乙個任務是寫者，則直接喚醒該寫者，否則將喚醒排在前邊的連續幾個讀者；

real-world concurrency

如果覺得對你有幫助，就點個在看吧，謝謝。

訊號量機制

1 訊號量的型別定義 訊號量 semaphore 的資料結構為乙個值和乙個 指標，指標指向等待該訊號量的下乙個程序。訊號量的值與相應資源的使用情況有關。當它的值大於0時，表示當前可用資源的數量 當它的值小於0時，其絕對值表示等待使用該資源的程序個數。注意，訊號量的值僅能由pv操作來改變。一般來說，訊...

訊號量機制

訊號量機制 整型訊號量 p操作 wait s.value s.value 1 if s.value 0 then block s,l v操作 signal s.value s.value 1 if s.value 0 then wakeup s,l 定義訊號量semaphore代表可用資源實體的數量...

訊號量機制

整型訊號量符合 有限等待 原則 signal釋放資源後，當cpu被分配給等待程序後，等待程序仍可繼續執行，可以符合 有限等待 但整型訊號量不符合 讓權等待 原則 整型訊號量的wait操作，當s 0時，當前程序會佔著cpu不斷測試 訊號量原語不能被打斷，這個占有cpu的程序會一直不斷的佔據cpu迴圈下...