2024q1 Homework5 (assessment)

contributed by < chloe0919 >

閱讀「因為自動飲料機而延畢的那一年」

看完這篇文章後，我覺得真實的反映了真實實作和理論上的差異，像是作者有提到 :

「資工系的學生不會寫程式，機械系的學生不會做機械」

這是我們在大學和研究所投入整整六年的時間都還有可能遇到的問題，學校教我們的雖然不僅僅只是理論，也會有一些實作的課程，但我們真實缺乏的是將理論和實作能力真正運用在解決問題和實際情況，這就像就學以來都在學習數學，但卻沒辦法將所學真正運用在日常生活解決問題一樣。

如果問題過於困難無法解決，那就重新定義問題吧！

其中作者在問題遲遲無法解決時說出了這句話，也讓我想起有時候在做研究和思考的時候，會因為原本的方向遇到一個問題而卡住，或許那時候該做的不是只有不停的思考，而是重新定義問題，有時候反而才能找出自己真正的糾結點在哪。

「你最大的問題在太害怕失敗了，既然都已經決定要延畢做飲料機了，那就要好好做，才不會辜負當初自己的期望。你可以計算要花多少錢，然後評估自己可以接受多少損失，畢業後慢慢還都好，要錢我也可以借你。但青春很貴，你也知道實習會發生什麼事，公司不會指派重要的工作給你，他們只會指派低風險的工作，你學習到的東西並不會比你現在多。你該學習的不是看到事情要完蛋了就去避免失敗，而是應該學習如何處理與承受失敗，你才能變得比以前更強大。」

我們經常都會因為害怕失敗而不敢去嘗試，就像做研究的時候偶爾會有一個嶄新的想法，但是卻會為了避免失敗而放棄，就像老師說的，應該嘗試學習承受失敗，有時候失敗會比成功收穫到更多的東西。

教材閱讀疑問

並行程式設計: Atomics 操作 :

1. 教材中提到「ARM 早期 CPU 使用的 SWP 指令在多核處理器中會遇上效能瓶頸」(主要問題在於 memory barrier)，不清楚為何 ARMv6 以上改用 LL/SC 指令可以解決效能瓶頸的問題
   ARM Synchronization Primitives Development Article

CISC 風格的處理器 (如 x86)，傾向提供 CAS (compare and swap/exchange)
RISC 風格的處理器 (如 Arm 與 RISC-V)，偏好 LL/SC。ldrex, strex -> exclusive monitor
https://developer.arm.com/documentation/dht0008/latest/arm-synchronization-primitives/exclusive-accesses/exclusive-monitors
Arm: SWP (Swap) and SWPB (Swap Byte) provide a method for software synchronization that does not require disabling interrupts. https://developer.arm.com/documentation/dht0008/a/swp-and-swpb/legacy-synchronization-instructions/swp-and-swpb

3. 根據 READ_ONCE() 巨集的定義，不清楚 __READ_ONCE 如何達到確保每次讀取符合 volatile 的操作，以及在 READ_ONCE(x) 中為什麼多使用 compiletime_assert_rwonce_type(x) 可以達到 atomic

READ_ONCE(x)、__native_word

/*
 * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
 * atomicity. Note that this may result in tears!
 */
#ifndef __READ_ONCE
#define __READ_ONCE(x)  (*(const volatile __unqual_scalar_typeof(x) *)&(x))
#endif

#define READ_ONCE(x) \
({ \
    compiletime_assert_rwonce_type(x); \
    __READ_ONCE(x); \
})

char *led = 0xFFF8888; // MMIO: memory-mapped I/O
*led = 1;

教材心得記錄

實作 Mutex lock

• mutex_trylock

static bool mutex_trylock(mutex_t *mutex)
{
    int state = load(&mutex->state, relaxed);
    if (state & MUTEX_LOCKED)
        return false;

    state = fetch_or(&mutex->state, MUTEX_LOCKED, relaxed);
    if (state & MUTEX_LOCKED)
        return false;

    thread_fence(&mutex->state, acquire);
    return true;
}

操作中總共檢查兩次 state，原因是在第一次檢查完後到第二次設置 lock 前可能會有其他執行緒在這期間獲取鎖，所以需要檢查第二次

簡述課程期末專題

並行程式設計

回顧〈並行和多執行緒程式設計〉教材和相關測驗題，強化對延伸問題的掌握

TODO: Quiz 9 測驗三 (work-steal) 含延伸問題
TODO: 閱讀指定的論文〈Cilk: An Efficient Multithreaded Runtime System〉，說明如何用 C11 Atomics 實作 deque 並建構足以進行 work-stealing 的並行結構
TODO: 實作「平行化」的資料排序程式

專題解說影片 : Linux 核心專題: 並行程式設計

專題 hackmd : Linux 核心專題: 並行程式設計