2025q1 Homework1 (ideas)

contributed by <weiso131>

作業書寫規範:

• 無論標題和內文中，中文和英文字元之間要有空白字元 (對排版和文字搜尋有利)
• 文字訊息 (尤其是程式執行結果) 請避免用圖片來表示，否則不好搜尋和分類
• 共筆書寫請考慮到日後協作，避免過多的個人色彩，用詞儘量中性
• 不要在筆記內加入 [TOC] : 筆記左上方已有 Table of Contents (TOC) 功能，不需要畫蛇添足
• 不要變更預設的 CSS 也不要加入任何佈景主題: 這是「開發紀錄」，用於評分和接受同儕的檢閱
• 當在筆記中貼入程式碼時，避免非必要的行號，也就是該手動將 c= 或 cpp= 變更為 c 或 cpp。行號只在後續討論明確需要行號時，才要出現，否則維持精簡的展現。可留意「你所不知道的 C 語言: linked list 和非連續記憶體」裡頭程式碼展現的方式
• HackMD 不是讓你張貼完整程式碼的地方，GitHub 才是！因此你在開發紀錄只該列出關鍵程式碼 (善用 diff 標示)，可附上對應 GitHub commit 的超連結，列出程式碼是為了「檢討」和「便於他人參與討論」
• 留意科技詞彙的使用，請參見「資訊科技詞彙翻譯」及「詞彙對照表」
• 不要濫用 :::info, :::success, :::warning 等標示，儘量用清晰的文字書寫。:::danger 則僅限授課教師作為批注使用
• 避免過多的中英文混用，已有明確翻譯詞彙者，例如「鏈結串列」(linked list) 和「佇列」(queue)，就使用該中文詞彙，英文則留給變數名稱、人名，或者缺乏通用翻譯詞彙的場景
• 在中文敘述中，使用全形標點符號，例如該用「，」，而非 ","。注意書名號的使用，即 〈 和 〉，非「小於」和「大於」符號
• 避免使用不必要的 emoji 字元

Linux 核心專題: 並行化的 Redis 實作

Userspace RCU 的 flavor

RCU 最常用在處理讀取多於寫入的情況，犧牲寫入的效能來最大化讀取操作。
RCU 一次只能有一個寫入者，這以 lock 保護。寫入的邏輯是先做出一個物件 (此時讀取端仍可自由讀舊物件)，然後更新 atomic 指標來指向新的物件。atomic 指標更新後，新的讀取端就會讀到新的物件。這讓寫入端完全不會擋到讀取端，適合讀取遠大於寫入的情況。

其中衍生的問題就是舊物件該如何釋放，若在讀取端仍在讀取舊物件時釋放會造成 segmatation fault ， 而更新完 atomic 指標後，到安全釋放舊物件的時間， 稱為 grace period。
要如何維持 grace period 的正確性，同時避免無止盡的等待，根據使用環境的不同， 會利用不同的 flavor 來解決問題。

參考

關於這方面我有個疑問:

1. 在文中下方的實驗結果顯示理論上應該表現最好的 QSBR 在實際測試中不如預期，然而，文中也提到 reader 要進行 1024 個讀取操作才進入 quiescent state ， 與 urcu 的 test_urcu_qsbr.c 相同。
   然而，我在 Linux 核心專題: RCU 研究 中看到，若使用者清楚知道 reader 該如何定期的進入 quiescent state ， 才不會讓 writer 被 block 太久。
   若能考慮實際應用場景，調整進入 quiescent state 需要的讀取操作(例如:
   10 ~ 100 之間)並重新設計實驗，是否會有不同的結果？

執行緒數量對 mt-redis 的影響

文中提到執行序數量的增加，在超過某個數字之後，會因為 context switch 與 cache miss 的增加而導致效率下降，這讓我想到過去在調整 p_thread 的執行序數量時，也有同樣的現象。

文中也提到了解決辦法，藉由加入 CPU affinity，讓兩個執行緒執行在同一個 CPU ，使任務不要頻繁在不同 CPU 切換，以減少 context switch 與 cache miss 的增加速度，增加可擴展性。