摘要：的科學(xué)定義是或者，它的標(biāo)志性原語(yǔ)是。能解決一類(lèi)對(duì)語(yǔ)言的實(shí)現(xiàn)來(lái)說(shuō)特別無(wú)力的狀態(tài)機(jī)模型流程即狀態(tài)。容易實(shí)現(xiàn)是需要和的一個(gè)重要原因。

前面寫(xiě)了一篇，寫(xiě)的很粗，這篇講講一些細(xì)節(jié)。實(shí)際上Fiber/Coroutine vs Async/Await之爭(zhēng)不是一個(gè)簡(jiǎn)單的continuation如何實(shí)現(xiàn)的問(wèn)題，而是兩個(gè)完全不同的problem和solution domain。

我們回顧一下最純粹的Event Model。這曾經(jīng)在UI編程，和現(xiàn)在仍然在microcontroller(MCU)編程中占據(jù)主力地位，在系統(tǒng)編程上是thread model了。

用MCU編程來(lái)講解最方便，在傳統(tǒng)UI編程上是一樣的。

單核的MCU具有硬件的Thread。

Main Thread是CPU的正常運(yùn)行，Interrupt Thread(一般稱(chēng)為ISR，Interrupt Service Routine)是硬件上的比Main Thread優(yōu)先級(jí)更高的Thread，即所謂的搶先(pre-emptive)。

如果Main Thread在運(yùn)行，有Interrupt進(jìn)來(lái)，CPU會(huì)立刻跳轉(zhuǎn)到ISR入口執(zhí)行，ISR原則上應(yīng)該保存現(xiàn)場(chǎng)，運(yùn)行，然后恢復(fù)現(xiàn)場(chǎng)，return。return之后Main Thread重新拿回CPU繼續(xù)運(yùn)行。這里壓棧彈棧的細(xì)節(jié)不說(shuō)了，這就是一個(gè)搶先CPU的過(guò)程。

在這種模式下編程，ISR里能訪問(wèn)的變量，和Main Thread里訪問(wèn)的變量，很明顯存在race，需要鎖機(jī)制。在系統(tǒng)級(jí)編程這種鎖機(jī)制就是lock，但是上述情況里Main Thread和ISR不是對(duì)稱(chēng)的，所以做法略有區(qū)別：Main Thread里lock的辦法是禁止interrupt，然后開(kāi)始執(zhí)行critical section的代碼，完成后使能中斷；ISR里，如果不考慮ISR之間的搶先的話，不需要這個(gè)過(guò)程，因?yàn)樗焐萂ain Thread優(yōu)先級(jí)高。

昨天我們說(shuō)了業(yè)界都在把non-blocking叫做asynchronous；這里解釋一下asynchronous，asynchronous的正確含義是你寫(xiě)了一個(gè)function，這個(gè)function在Main Thread和ISR里都能用，它叫做asynchronous function；如果是系統(tǒng)級(jí)編程，thread之間是對(duì)等的，它叫做thread-safe。

上述的模型在邏輯上沒(méi)問(wèn)題，但是有兩個(gè)實(shí)踐上的麻煩：

asynchronous function不好寫(xiě)，尤其是出現(xiàn)nested，在ISR有搶先的時(shí)候就更加麻煩；

禁止中斷的時(shí)間不能太長(zhǎng)，太長(zhǎng)的話會(huì)丟失中斷處理，邏輯上會(huì)出現(xiàn)問(wèn)題；

ISR里的執(zhí)行邏輯時(shí)間也不能太長(zhǎng)，尤其不能等待什么，否則Main Thread會(huì)被block太久；

所以聰明人就有一個(gè)one-for-all的辦法：

在全局構(gòu)造一個(gè)event queue；

任何ISR進(jìn)來(lái)的時(shí)候，不去做邏輯處理，只把當(dāng)時(shí)和中斷有關(guān)的狀態(tài)保存下來(lái)，構(gòu)造一個(gè)event，壓入隊(duì)列；

在Main Thread里一個(gè)一個(gè)的取event，調(diào)用相應(yīng)的event handler處理。

在這個(gè)模式下：

只有event queue是需要lock的；唯一的race發(fā)生在存取event的時(shí)候，存不用lock，取的時(shí)候禁止和使能中斷，這個(gè)時(shí)間不長(zhǎng)，避免丟失中斷。

中斷的真正處理邏輯實(shí)際上發(fā)生在Main Thread，相當(dāng)于deferred，它有延遲，但是不會(huì)亂序。

所有的代碼段都運(yùn)行在Main Thread，沒(méi)有race，也就是人們最推崇event model的特性之一：run-to-completion。

它對(duì)于硬件搶先的多線程是個(gè)非常好的簡(jiǎn)化。

那么有了Event，代碼模塊化的結(jié)果就是用State Machine建模。State Machine是一個(gè)理論上萬(wàn)能的模型，任何代碼模塊你都可以給出state/event行為矩陣，稱(chēng)為state transition table。它是對(duì)這個(gè)模塊的完備定義，也極具可測(cè)試性，也應(yīng)用非常廣泛。OO編程的本質(zhì)是State Machine建模，所有的method都可以看作是event，它可能引起Object的狀態(tài)遷移。在良好設(shè)計(jì)下，State具有邊界，即所謂的封裝。每個(gè)State都有owner，不是owner不能修改它，避免side-effect。

在實(shí)踐中，目前沒(méi)有任何一個(gè)流行語(yǔ)言能直接寫(xiě)出簡(jiǎn)潔的狀態(tài)機(jī)，尤其是狀態(tài)機(jī)組合；所以它存在于Pattern層面而不是語(yǔ)言層面；客觀的說(shuō)這是計(jì)算工業(yè)的恥辱，但我們只能接受現(xiàn)狀。

IO不是象中斷一樣的自發(fā)事件。在通訊編程領(lǐng)域大家發(fā)明了一對(duì)名詞來(lái)描述這個(gè)問(wèn)題：solicited和unsolicited；不算特別恰當(dāng)?shù)锌偙葲](méi)有好。

IO是solicited，即有request才會(huì)有response；不需要request的那種自發(fā)event，是unsolicited event。

Event Model在處理這個(gè)問(wèn)題上沒(méi)有理論上的障礙，你可以對(duì)調(diào)用函數(shù)對(duì)外界進(jìn)行一個(gè)操作，然后得到結(jié)果時(shí)構(gòu)造一個(gè)事件。

但是在實(shí)踐上，即使不考慮效率問(wèn)題，這里仍然有一個(gè)大麻煩：在代碼層面上，執(zhí)行request的地方在一個(gè)函數(shù)里，被某個(gè)event handler直接或間接調(diào)用，處理response的event handler在另一個(gè)地方。代碼的可讀性和可維護(hù)性都是完全沒(méi)有保障的，代碼質(zhì)量取決于你的信仰、星座、美食愛(ài)好、或者性取向。

我們需要一些技術(shù)讓代碼看起來(lái)是人類(lèi)的，不是AI或者外星人的，來(lái)對(duì)付IO問(wèn)題。

更寬泛的說(shuō)，Thread Model，Unix進(jìn)程，Unix的一切皆IO哲學(xué)，Unix的open/read/write/close包打天下，就是我們?cè)诮鉀Q這類(lèi)問(wèn)題上的第一個(gè)大范圍成功的案例。但是Thread Model這個(gè)話題太大了，它還包括系統(tǒng)資源的虛擬化和物理多CPU的并發(fā)，所以我們不用這種擴(kuò)大化的概念來(lái)討論。我們只討論兩個(gè)限定在單進(jìn)程Event Model下的技術(shù)：coroutine和callback。

Coroutine也是一個(gè)擴(kuò)大化的概念。我們先討論廣的概念邊界，再來(lái)說(shuō)它對(duì)io問(wèn)題的解決辦法。

Coroutine的科學(xué)定義是stateful或者stackless function，它的標(biāo)志性原語(yǔ)是yield。

注意原語(yǔ)(primitive)是理解一種編程語(yǔ)言或者編程技術(shù)的最關(guān)鍵點(diǎn)。如果一種技術(shù)致力于解決某個(gè)特定問(wèn)題，它最好的辦法不是用pattern來(lái)解決，而是定義原語(yǔ)。OO語(yǔ)言有class，extends，implements；函數(shù)式語(yǔ)言允許function作為primitive value寫(xiě)入assignment expression；以解決并發(fā)為目標(biāo)的Go語(yǔ)言把channel作為標(biāo)志。

yield是什么意思呢？它說(shuō)的不是io，它說(shuō)的是cpu，交出cpu。從這個(gè)意義上說(shuō)，coroutine第一解決的問(wèn)題是調(diào)度。它解決其他問(wèn)題，包括timer/sleep，包括io，包括把一個(gè)整體計(jì)算切碎成很多單元來(lái)實(shí)現(xiàn)，都是靠yield。所以正確的表述是：Coroutine不是為特別解決io問(wèn)題的設(shè)計(jì)，它首先解決cpu調(diào)度，它可以用于解決io問(wèn)題。

第二點(diǎn)，為什么我們需要coroutine？它最擅長(zhǎng)解決的問(wèn)題是什么？

coroutine本質(zhì)上仍然是一個(gè)event / state model，是一個(gè)object，但是不同的是，你不需要把所有的state都顯式表達(dá)出來(lái)，以對(duì)付continuation問(wèn)題，coroutine允許開(kāi)發(fā)者直接用語(yǔ)言提供的原始流程語(yǔ)句，來(lái)編碼state信息，你運(yùn)行到哪里，這個(gè)時(shí)候整個(gè)coroutine內(nèi)的local variable的組合，就是當(dāng)前的state，每運(yùn)行一次，就是一次state transition；和對(duì)象一樣它要從構(gòu)造開(kāi)始，到析構(gòu)結(jié)束(return)。

coroutine能解決一類(lèi)對(duì)OO語(yǔ)言的state pattern實(shí)現(xiàn)來(lái)說(shuō)特別無(wú)力的狀態(tài)機(jī)模型：流程即狀態(tài)。如果你的狀態(tài)機(jī)model的是一個(gè)復(fù)雜流程，充滿條件分支、循環(huán)、和他們的嵌套，用coroutine寫(xiě)起來(lái)非常簡(jiǎn)單，而與之對(duì)應(yīng)的狀態(tài)機(jī)，都不用寫(xiě)代碼，定義transition table的時(shí)候程序員就要進(jìn)醫(yī)院了。

coroutine對(duì)付io了嗎？yes and no。它是標(biāo)準(zhǔn)的Thread Model，thread model下io什么樣，它就什么樣了，no more, no less。

這幾個(gè)貨本質(zhì)上是一樣的，區(qū)別在形式上。當(dāng)然很多時(shí)候形式很重要，但是我們先談本質(zhì)。

const myFunction = (dirpath, callback) => {
  // do something
  // first io operation
  if (err) 
    return callback(err)
  else
    return callback(null, entries)
}

// my code
myFunction("/home/hello", (err, entires) => {
  // blah blah blah
})

// do something else
console.log("blah, blah...")

我們首先說(shuō)callback的本質(zhì)是一個(gè)event handler。調(diào)用myFunction相當(dāng)于在前面說(shuō)的最淳樸的event model里enqueue一個(gè)event，這個(gè)event的handler會(huì)根據(jù)event里定義的dirpath執(zhí)行某個(gè)操作，操作結(jié)束的時(shí)候會(huì)構(gòu)造另一個(gè)event，里面包含error或result。

這個(gè)純粹模型的寫(xiě)法會(huì)非常復(fù)雜，從這個(gè)意義上說(shuō)，node.js callback是一種簡(jiǎn)單的continuation實(shí)現(xiàn)。

But wait! 兩者不是完全一致的!

myFunction函數(shù)里入口處do something部分的代碼；如果是我們上述的淳樸event model，它會(huì)在當(dāng)前代碼結(jié)束之后執(zhí)行，即console.log會(huì)先執(zhí)行，等到全局的event manager開(kāi)始層層dispatch event的時(shí)候，這個(gè)請(qǐng)求才可能landing到正確的handler，這段do something才開(kāi)始執(zhí)行，在console.log之后。

這是一個(gè)subtle，但是極為重要的區(qū)別。

插個(gè)話：callback形式如果在入口處do something立刻返回的話，對(duì)外部調(diào)用者來(lái)說(shuō)是一場(chǎng)災(zāi)難，因?yàn)樗緵](méi)辦法確定它提供的callback在console.log之前還是之后執(zhí)行。所以callback形式要guarantee它是異步的，用process.nextTick。promise和async/await在這個(gè)問(wèn)題上是一大進(jìn)步，它有異步保證，即使代碼形式上看起來(lái)是同步返回。

現(xiàn)在我們?cè)谧约耗X袋上敲一錘子，昏過(guò)去，醒來(lái)的時(shí)候站在V8虛擬機(jī)的中控臺(tái)上。V8激進(jìn)的inline函數(shù)來(lái)提高執(zhí)行效率，在源碼層面上的myFunction函數(shù)調(diào)用，對(duì)V8編譯的代碼來(lái)說(shuō)有一個(gè)call/return的邊界嗎？probably not！對(duì)編譯代碼來(lái)說(shuō)，極大的可能性是執(zhí)行函數(shù)邊界在myFunction內(nèi)部第一個(gè)io處，而不是函數(shù)入口。

如果仍然用淳樸Event Model來(lái)類(lèi)比，enqueue的event是一個(gè)純粹的io操作請(qǐng)求，而不是要執(zhí)行myFunction函數(shù)！

所以寫(xiě)到這里，一個(gè)關(guān)鍵的概念問(wèn)題闡述清楚了：

coroutine is all about how to structure your control flow unit, while node callback is all about how to structure your io operation.

他們的出發(fā)點(diǎn)完全不同。

在建模層面（而不是語(yǔ)言技術(shù)層面）Funtional Programming，F(xiàn)P，它不是OO的對(duì)立，而是OO的超集。

在FP模型下，程序分為三個(gè)部分：Pure Functions，OO (state monads)，和io (io monads)。

Pure的部分里，Pure Function只有輸入輸出（函數(shù)的輸入輸出，不是io輸入輸出），function和immutable數(shù)據(jù)結(jié)構(gòu)是孿生姐妹。

OO的部分，如果程序需要state，OO至少在JavaScript里是絕對(duì)的最佳實(shí)踐，只有少量場(chǎng)合可以用閉包代替。

io的部分，應(yīng)該多帶帶抽象出來(lái)，用callback、promise或者async/await做薄層封裝。

站在Pure Function的角度看，state和io都是它的外部世界。

Side Effect一詞最廣的使用上指的是一個(gè)函數(shù)是不是pure。io function毫無(wú)疑問(wèn)不pure，但是訪問(wèn)state的呢？比如前面的代碼里，如果myFunction修改了它的調(diào)用者域內(nèi)的閉包變量呢？這也是side effect。

在OO里我們保障減少side effect的影響的辦法，對(duì)于state（而不是io）范疇的變量來(lái)說(shuō)，是用封裝原則來(lái)保障的。

在FP里對(duì)這個(gè)問(wèn)題的有效辦法，則是immutable。

比如上面的代碼，如果你傳入myFunction的參數(shù)是一個(gè)對(duì)象，有深層次的結(jié)構(gòu)，你會(huì)設(shè)計(jì)myFunction的函數(shù)約定是我要修改某個(gè)參數(shù)嗎？或者你會(huì)防止其他程序員這樣做嗎？

簡(jiǎn)單的辦法就是用immutable來(lái)處理在pure function domain的這類(lèi)問(wèn)題，大家都用immutable；即使你沒(méi)有顯式的包含某些immutable庫(kù)，JavaScript里也有大量的集合類(lèi)函數(shù)已經(jīng)這樣做了。

Lock分為兩類(lèi)，atomic operation lock，和transactional lock。

transactional lock指的是一個(gè)操作的結(jié)果是all or none的，包括更新state，也包括執(zhí)行output io操作。

容易實(shí)現(xiàn)transactional lock是需要fp和immutable的一個(gè)重要原因。因?yàn)樗屵@種lock容易書(shū)寫(xiě)。

你可以用一種鎖對(duì)付兩種情況。但是很難。用Big lock并發(fā)效率有問(wèn)題，細(xì)粒度鎖編程難度大；而且對(duì)于JavaScript的單進(jìn)程Event Model來(lái)說(shuō)，用細(xì)粒度鎖對(duì)付transactional的數(shù)據(jù)完整性問(wèn)題是overkill的。

另外一種鎖機(jī)制是Opportunistic lock，它和數(shù)據(jù)庫(kù)的事務(wù)操作是同樣的邏輯：你不斷的執(zhí)行更新數(shù)據(jù)的操作，實(shí)際上是創(chuàng)建了一個(gè)副本，在最后commit的時(shí)候全部生效或失敗。如果失敗了可以重試這個(gè)過(guò)程。

在有immutable數(shù)據(jù)保證的情況下，如果有多步io操作導(dǎo)致更新過(guò)程分了幾個(gè)步驟，這個(gè)不是問(wèn)題，你一直在創(chuàng)建一個(gè)副本，在最后需要更新state monad的時(shí)候，用referential equality check檢查input是否發(fā)生了變化（你也可以每一步都做，但幾率上說(shuō)意義不大）。

這樣書(shū)寫(xiě)事務(wù)問(wèn)題，即使對(duì)文科生改行來(lái)的程序員來(lái)說(shuō)也不算太難。

在某些情況下IO操作的原子鎖無(wú)可替代；

比如你要更新一個(gè)文件，你可以用時(shí)間戳來(lái)替代上面說(shuō)的immutable referential check，即先讀入文件時(shí)間戳，寫(xiě)入前檢查時(shí)間戳是否發(fā)生變化，這么做能大大減少race的幾率，但不是解決了問(wèn)題，因?yàn)樽x入時(shí)間戳本身和寫(xiě)入文件操作沒(méi)有原子性，可以出現(xiàn)race。

那么這種時(shí)候封裝原子操作是必要的，傳統(tǒng)的early lock也必要，但這是最細(xì)粒度鎖，它屬于原子操作鎖而不是事務(wù)鎖。

事務(wù)鎖本質(zhì)上是big lock，即使要提高效率也只是每步操作檢查input，沒(méi)有邏輯難度，只有代碼量。

文件系統(tǒng)io是有需要寫(xiě)原子操作鎖的情況的，數(shù)據(jù)庫(kù)和api操作應(yīng)該由提供者保證rmw操作(read-modify-write)，如果需要的話。

所以問(wèn)題不是簡(jiǎn)單的fiber/coroutine vs async/await之爭(zhēng)，而是要站在更大的problem domain去全局的看。程序員需要的是全局的和一致的解決方案。

在前面的討論上說(shuō)過(guò)了，fiber/coroutine完全是關(guān)于調(diào)度控制流程的，而callback/promise/async/await完全是關(guān)于結(jié)構(gòu)化io操作的；兩者沒(méi)在同一個(gè)角度上談問(wèn)題。

fiber/coroutine不是完整的問(wèn)題答案，除非你的problem domain里最重要的問(wèn)題是如何并發(fā)計(jì)算任務(wù)，io無(wú)所謂；

async/await回答了如何結(jié)構(gòu)化io操作的問(wèn)題，結(jié)合fp/immutable回答了如何在維護(hù)state和更新外部世界時(shí)解決事務(wù)性競(jìng)爭(zhēng)問(wèn)題。它是一個(gè)一攬子解決辦法，而且不難。

在針對(duì)state維護(hù)的問(wèn)題上，state machine/event/state model是合格的，但是它與重io操作時(shí)的結(jié)構(gòu)化io操作尤其是transactional更新問(wèn)題沒(méi)有直接答案。nodejs本身不是general purpose的系統(tǒng)級(jí)開(kāi)發(fā)語(yǔ)言和環(huán)境，它是domain specific language (dsl)。

我們不能說(shuō)coroutine或者csp/channel在JavaScript上完全沒(méi)有意義，但是nodejs在io并發(fā)上已經(jīng)做得很好，而如果還要在計(jì)算任務(wù)并發(fā)上做得很好，支持多核，目前看差距太大了，需要解決的問(wèn)題很多很多。

JavaScript的未來(lái)肯定不在于目前worker引入的鎖，這是個(gè)joke，屬于monkey-patching。

在系統(tǒng)語(yǔ)言里不得不用的細(xì)粒度鎖也不該在JavaScript里出現(xiàn)，也不該用于解決事務(wù)問(wèn)題。

Opportunistic Lock是被數(shù)據(jù)庫(kù)領(lǐng)域證實(shí)的和被廣泛接受的solution，只是在語(yǔ)言一級(jí)去實(shí)現(xiàn)primitive支持上有困難。它需要：

JS語(yǔ)言和JSVM真正支持immutable數(shù)據(jù)類(lèi)型；

在JSVM里有Software Transactional Memory的實(shí)現(xiàn)；

理論上STM支持多核是沒(méi)問(wèn)題的，系統(tǒng)語(yǔ)言的STM庫(kù)有很多成熟的，但是JS的語(yǔ)言對(duì)象模型是list/hash table，在JIT層面上又要編譯成類(lèi)型對(duì)象，所以把對(duì)象模型扣在內(nèi)存模型上并不簡(jiǎn)單。

你應(yīng)該花上幾周的時(shí)間了解一下Haskell。

Haskell是靜態(tài)語(yǔ)言，最純粹的simple typed lambda實(shí)現(xiàn)；它有著匪夷所思的強(qiáng)大的代數(shù)類(lèi)型系統(tǒng)，但是到底是靜態(tài)的代數(shù)類(lèi)型系統(tǒng)是未來(lái)，還是JIT的動(dòng)態(tài)類(lèi)型系統(tǒng)是未來(lái)，只有時(shí)間能回答了。

它有個(gè)搞笑的do語(yǔ)法，async/await該做的是就是haskell里do該做的。do/io monad也是最能說(shuō)明白nodejs callback的設(shè)計(jì)初衷和最恰當(dāng)?shù)膽?yīng)用場(chǎng)景的。

在pure function, state monad, 和io monad之間劃分清楚的界限，是程序建模的巨大進(jìn)步，而不是把io封裝在OO對(duì)象的操作里，它等于沒(méi)有區(qū)分state和io的不同。

無(wú)論用任何語(yǔ)言編程，這個(gè)建模方式和劃分模塊的辦法都是極具借鑒意義的；除非你的程序真的和老式程序一樣只需要封裝簡(jiǎn)單的幾個(gè)文件操作。

時(shí)代不同了，web和network改變了我們編程的問(wèn)題域，相應(yīng)的我們?cè)诮夥ㄓ蛐枰滤季S也就理所應(yīng)當(dāng)。