第一章
印象:
硬件PCI/ISA的架構
North Bridge相當于人的心臟，連接所有高速設備，CPU ->大腦
南橋芯片則負責低速設備連接
SMP
中間層 是解決很多問題的大方向
Any problem in computer science can be resolved by another layer of indirection
CPU密集型 IO密集型
這兩種類型的Process，理論上優先級高的，也就是說最應該先得到CPU的是IO密集型
通俗的理解應該是IO密集型做完事情花的CPU時間最少，然后就會等待IO設備的反應，這樣可以讓設備性能最大化
Memory
分段分頁 MMU
線程安全和線程模型
其中線程安全有兩件事情要注意
Semaphore
Mutex
上面這兩個可以做成全局的，并不一定是By Process的，例如POSIX pthread在
對Mutex做attr設定的時候就可以指定為 shared process
也就是說一個Process可以加鎖，另外一個可以釋放他。
另外這種Mutex必須處在共享內存中，否則沒辦法訪問。有親緣關系的Process可以通過mmap一個匿名映射做到
anyway有很多方式了。
Critical Section
這個是Inter Process的東西。
關于線程互斥的lock的問題
RW lock就是對普通lock記錄兩個狀態來供read or write操作選擇
屬于線程本身的東西 TLS/Stack/Register
有時候編譯器會為了做優化
內存和寄存器的數據會出現不sync的狀態。
即使你用lock來做保護,也不一定能OK。然后volatile就出現了。
volatile最主要的作用就是thread內保證編譯器不要做優化，防止這種不sync帶來的問題。
一般是這樣例如x變量，thread_1讀到x變量放到了寄存器中，因為可能馬上會再訪問它，那么對x進行操作后就不會寫回內存
這樣即使你加了lock，這個時候lock也被釋放掉了（操作完成），但是結果未能Sync，那么thread 2來訪問x的時候，在內存
中拿到的值就變成dirty狀態了。
另外一種過度優化就是CPU做的優化，有些上下語義無關的指令，CPU有可能會調整運行順序。
書中有個經典樣例
一段 Singleton pattern的double-check的代碼
volatile T* pInst = NULL;
T* getInstance()
{
if (pInst == NULL)
{
lock();
if (pInst == NULL)
pInst = new T();
unlock();
}
return pInst;
}
這里有兩點
第一，double-check 也就是雙if能避免過多的無用的get lock，降低消耗
對臨界區需要做保護的資源，可以提前去取狀態，如果符合自己的預期，而且短時間不會有變化，那么就不用去拿鎖了
不知道為啥我想到了unlikely，但仔細想一下，功能完全不同。
第二點也就是要說的CPU的過度優化
這里已經是聲明volatile了，所以沒有寄存器和內存不sync的問題
但是由于這里new需要先 malloc出空間，然后call T的constructor。
所以有可能會發生這種情況，malloc出空間后，把地址付給pInst，然后去做初始化；
這樣就有可能另外一個線程取得的object是沒有被完全初始化好的，是否會出問題depend on T的具體實現了。
許多CPU提供了barrier指令用來解決上面提到的問題。
線程模型
這個東西，我看了下，開始沒看明白，這邊書這個東西沒講清楚，后來去網上找了些資料。用戶線程和內核線程的對應關系取決于調度單位。
也就是說內核把什么東西當做一個調度單位
拿Linux來說吧，Process是線程集和資源集
調度的時候，那些共享資源的Task（thread）之間的調度肯定比那些跨Process不共享資源的thread做context switch消耗的資源
多得多。
基于調度消耗之類的考量
模型分為下面幾種
一對一，也就是說 user space create出來的線程就是和kernel的調度單位相同，稱一一對應
一對多，應該是這樣一種情況，kernel看到的是Process，userspace自己實現出來自己的thread，這個thread，kernel是不知道的
調度的時候kernel負責分批CPU給他能看到的Process，上層userspace自己來調度分配這個Process獲得的CPU time給這個process中的
各個線程。
這樣的分配就可以保證在一定的時間內只需要做一些register和stack的切換，不會有memory等等的switch。
壞處是上面的thread只要一個被suspend，那么這個Process里面的其他thread也就被suspend住了，一般上層調度程序
不會假定其他的thread能run，所以一般會是kernel把CPU time給其他process
多對多，就是一種混合的情況了，我想到了Android，但是Android是一對一模型，dalvik會保證Java thread對應下面一個
native thread，想說的是，這種虛擬機架構可以做成多對多的樣子，一個native thread run一個JVM，JVM開出來很多Java Thread，
JVM負責調度這些Java Thread，Native負責調度JVM所在的Thread。
不知道我有沒有講錯。