golang、c++，並發、並行（一）
正式接觸golang大半個月，寫了幾個練習項目，讓人有些感概。
Golang這樣的自動化內存管理水平和並發調度能力，讓我印象很深。
單是那樣的內存管理水平，通過加入特定的並發優化c++內存池，我可以做到。
那種並發調度能力，通過引入復雜的調度算法，也勉強可以做到。
但是這兩個加在一起，配合出色的跨平台標准庫，組成這樣的一個並發友好跨平台生態，這我五年之內可能都做不到。
沒有用c++寫過高並發代碼的人，可能很難理解這種復雜的情緒。
這是一種，久渴的人，突然在沙漠中看到一片綠洲的感覺，驚喜萬分；而后又發現原來這個綠洲一直就在你身旁。但你卻不停錯過的悔恨。
c++的高並發編程，一個聽的人感覺很有逼格，寫的人累死的事情。
這是在11版前，甚至連跨平台線程模型都沒有的環境。
這是連標准庫一個小小的random生成器都沒有實現並發安全性的環境。
這是一個需要面對海量第三方庫，然后基本上沒有文檔，和一堆編譯問題和運行bug的環境。海量到，最后已經完全麻木，只感覺眼前不停地飛過一個又一個庫名，一個又一個錯誤。等你費了吃奶的勁，終於都正常運行了。才又發現，只是串行情況下運行正常。那並發運行呢？
這是一個在沙子上建立的樓房。或許一聲咳嗽后，就會頃刻倒塌。
就是這么一片糟糕的環境。撲面而來的蠻荒與原始，讓你懷疑還活在上個世紀，活在穿孔卡片式計算機的時代。
06年，計算機正式進入多核元年。
以前只在大型機、小型機上，使用的昂貴玩意兒，開始大規模出現在桌面pc和廉價服務器上。
一個讓硬件工程師，大松一口氣，“終於他媽的，從功耗、主頻陷阱解脫了。”他們成功的甩掉了一個沉重的包袱。
而軟件工程師，開始戴上了沉重的枷鎖。心里一萬頭。。。奔過。“免費午餐”正式結束。
並發、並行兩個坑爹貨正式進入大多數程序員的視野。
線程級的並發、並行
線程級並發，是一種使用多線程進行程序流程設計的方式。（和單核的指令級並行不同）
在單核時代，主要是應用於gui，網絡通信等要求低延遲高響應的場景。
線程級並行，是一部分並發在多核cpu上的一種表現。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
簡單舉例：
程序a，包含100斤肉、50斤淀粉、10斤香辛料。
單核cpu，一座火腿腸工廠。
串行：
100斤肉-->50斤淀粉-->10斤香辛料-->火腿腸工廠-->火腿腸
把肉、淀粉、香辛料運入工廠，一分鍾（60秒）后，工廠生產出160斤火腿腸。
現在客戶說一分鍾太久了，要一邊運進原料一邊生產出火腿腸。降低出貨時間。
並發：
10斤肉-->5斤淀粉-->1斤香辛料-->火腿腸工廠-->火腿腸
（然后重復）
10斤肉-->5斤淀粉-->1斤香辛料-->火腿腸工廠-->火腿腸
。。。
現在可以做到0.1分鍾（6秒鍾）就生產出16斤火腿腸。
現在老板說火腿腸生產的太慢，要擴大工廠規模。於是找來了工程師，工程師說，繼續擴大單個工廠成本太高，划不來。不如，再建一座新工廠。
程序a，包含100斤肉、50斤淀粉、10斤香辛料。
雙核cpu，兩座火腿腸工廠，工廠a、工廠b。
繼續用上面並發生產方式：
（兩座工廠同時生產）
10斤肉-->5斤淀粉-->1斤香辛料-->火腿腸工廠a-->火腿腸
10斤肉-->5斤淀粉-->1斤香辛料-->火腿腸工廠b-->火腿腸
現在0.1分鍾（6秒鍾）運入20斤肉、10斤淀粉、2斤香辛料，
（10*2斤肉、5*2斤淀粉、1*2斤香辛料）
生產出32（16*2）斤火腿腸。
這就是並行。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
下一篇結合語言繼續扯。。。