在多線程編程中，我們使用互斥鎖（Mutex）來解決數據混亂問題。但如果鎖用得不對，就會引發一種更嚴重的後果——死鎖（Deadlock）。 首先要糾正一個概念：死鎖不是一種鎖的類型，而是由於錯誤使用鎖，導致程序陷入的一種永久阻塞（卡死）的狀態。 今天我們通過代碼，現場還原兩種最常見的死鎖場景。 一、 第一種死鎖：作繭自縛 (Repeated Loc
在上一篇博客中，我們見識了多線程“裸奔”（無同步機制）時導致的銀行賬户錯誤和打印亂碼。為了解決這些問題，我們需要引入一種機制，保證同一時刻只有一個線程能訪問共享資源。 這個機制就是互斥量（Mutex）。你可以把它想象成洗手間門上的鎖：“有人佔用，閒人免進”。 一、 互斥鎖的“使用説明書” 互斥鎖本質上是一個結構體 pthread
在Linux進程間通信（IPC）的大家族裏，管道（Pipe）無疑是那位最平易近人、最容易上手的成員。它就像進程間的“對講機”，簡單、直接、高效。然而，正如每一位性格鮮明的朋友一樣，管道也有它的“脾氣”和“原則”。 今天，我們就來深入聊聊這位“老朋友”，看看它迷人的簡潔之處，也直面它那兩個最核心的“侷限”，最終學會何時該毫不猶豫地選擇它，何時又該果斷地尋找替代方案。 一
我們已經學會了如何用父子進程模擬 ls | wc -l。現在，讓我們挑戰一個更真實的場景：讓父進程扮演“總指揮”的角色，創建兩個“兄弟”子進程，讓它們一個執行ls，一個執行wc -l，而父進程只負責統籌和善後。 這聽起來只是個小小的改動，但一個“幽靈”般的陷阱正潛伏其中。無數開發者曾在這裏折戟，他們的程序看似完美，卻在運行時神秘地卡住，一動不動。 今天，我們就來當一回
