# 2024q1 Homework5 (assessment) contributed by < `Shiang1212` > ## 閱讀〈[因為自動飲料機而延畢的那一年](https://blog.opasschang.com/the-story-of-auto-beverage-machine-1/)〉的啟發 每次看完類似的勵志故事後，都會有種莫名的鼓舞人心，我以前很喜歡這種感覺，憑著這份感動覺得好像自己也能做出什麼成就。後來才發現理想終究是美好的，往往只看見別人的成果，卻沒注意到背後為其付出的努力，明知自己不如別人聰明，也不如別人認真，卻妄想著能成一樣的大事，簡直就是癡人說夢。就像老師說的，做事不能眼高手低，在勇敢追求目標時，也要了解自己的實力大概是什麼等級，並時刻提醒自己缺什麼就補什麼，我想這才是成大事的關鍵。 > 你不能現在就放棄，要是現在就放棄的話，你這輩子日後遇到這種等級的困難，就只會想逃避而已。 這句話讓我想到〈灌籃高手〉中安西教練的一段話：「現在放棄的話，比賽就結束了」。在塵埃落定之前，沒有什麼事是徒勞無功的，不輕言放棄，堅持到最後一刻，即便最後結果像本文一樣，耗時 14 個月的計畫終究以失敗告終，這段期間的努力也必能化作成長的養分，成為成功路上的一顆墊腳石。 > 然後我發現一個原本以為只有在資工系發生的現象，那就是「資工系的學生不會寫程式，機械系的學生不會做機械」。 看到這句話我真的直接破防，在修這堂課之前，我就是老師口中說的那些考試考個幾分就覺得自己了解這個學科的那種人，從沒想過自己的專業知識是那麼的不堪一擊，追求學問的態度也十分畸形。在作業一實作佇列操作時，我為了趕上進度，面對問題我沒有做太多的探討，反而是大量參考同學的筆記，雖然很快就寫完了，但我到底學到了什麼呢？在第五週我終於認命了，就算進度緩慢也不要投機取巧，誠實面對問題才是最重要的，希望在學期結束之前，我能儘可能學習，不愧對自已。 ## 研讀教材並紀錄課程疑惑 ### [Linux 核心設計: 淺談同步機制](https://hackmd.io/@sysprog/linux-sync) * Mutex 和 Binary Semaphore 都是當有多個 process 請求存取 CS 時，確保一次只會有一個 process 對共用資源的操作，只是差在 Mutex 有 owner 的概念而 Binary Semaphore 沒有，想問實際應用上兩者有什麼差別嗎？兩者使用上會有什麼特別的考量嗎？ > 參見 [並行程式設計: POSIX Thread](https://hackmd.io/@sysprog/posix-threads) 及 [並行程式設計: Lock-Free Programming](https://hackmd.io/@sysprog/concurrency-lockfree) > semaphore 重視「總量控管」 => producer-consumer (bounded buffer problem) > mutex 適合 reader-writer problem * Linux 實作 Mutex 分成三個步驟，其中第一步 Fast path 嘗試使用 atomic operation，減少 counter 數值來獲得鑰匙。想問這個 counter 指的是什麼。 > 對照看上方材料，注意通知 (signaling) 的機制 > https://hackmd.io/@sysprog/concurrency/%2F%40sysprog%2Fconcurrency-mutex ## 簡述想投入的專案 ### 作業及測驗題 作業的完成進度十分有限，希望能儘可能完成。 ### 並行程式設計 回顧〈並行和多執行緒程式設計〉教材和相關測驗題，強化對延伸問題的掌握。 ### Linux 核心同步機制研究-RCU [Linux 核心專題: RCU 研究](https://hackmd.io/@sysprog/ry_6RHgS3#qsbr-memb) ### 改進 Linux 核心的 lib/{list_}sort.c 大學時期疏於學習，沒有太好的數學能力與專業知識，希望能透過這個專案，除了重新複習資料結構與演算法，並嘗試做出貢獻。 --- TODO: [Quiz 10](https://hackmd.io/@sysprog/linux2024-quiz10) 的測驗 2 (lfq: 精簡的並行佇列)，利用 [Quiz 12](https://hackmd.io/@sysprog/linux2024-quiz12) 測驗 3 提到的效能分析方法，量化實作表現 (without RCU vs. with RCU) > scalability AAAA : &ctx->is_freeing, &old, 0