進程間通信
三個問題：
進程間的信息傳遞方式
對共享變量的訪問
進程間執行順序的問題競爭條件：多個進程訪問共享變量，結果取決於進程運行時的精確時序。
臨界區：
互斥訪問
忙等待互斥：屏蔽中斷、鎖變量、嚴格輪換、Perterson解法、TSL指令。
睡眠與喚醒方式。生產者消費者問題：
之前接觸時以爲弄懂了，現在細想其實不然，以爲一個共享變量的互斥訪問就可以解決，no！
Cpu在即將睡眠的前一刻輪轉，有可能導致wakeup信號丟失。現在再看信號量的解決方案。
信號量與互斥量
爲了解決忙等待的低效率問題（有時甚至優先級反轉的永遠等待問題）， 採用睡眠與喚醒的方式來進行。用睡眠與喚醒來應對生產者消費者問題時，還是會遇到競爭條件，造成的原因是喚醒可能會丟失，因此，提出要記錄喚醒次數的想法，由此誕生了信號量—用來累計喚醒次數：down操作和up操作（原始稱爲P、V操作），分別對應sleep和wakeup操作。
其解決問題的本質是把down操作和up操作原子化，具體來說，down操作如果不引起睡眠，則原子操作過程包括：測試值，更新值；如果會引起睡眠，則包括：測試值，睡眠開始。Up操作肯定不會引起睡眠，如果up操作的信號量先前沒有其他進程在其上睡眠，則包括：測試值，增加1；如果有1到多個其他進程在其上睡眠，則包括：測試值，喚醒某個睡眠的進程。
以上是個人學習後的一點理解。
操作原子化得底層實現大致就是採用系統調用實現，期間屏蔽中斷。二元信號量—互斥量
互斥量應用還是比較廣泛的，如Java中的鎖，因爲在用戶空間實現的線程中，操作系統是感知不到多線程的存在的，所以也就不可能爲線程調度時間片，此時就不能用忙等待的方式(但是貌似也是有自旋鎖這一概念的，用戶空間去實現?)，而利用互斥量的方式配合thread_yield則可以較好的解決這一問題。- 條件變量
配合互斥量的使用，典型的消費者生產者問題。
