為什么80%的碼農都做不了架構師？>>> ??

多線程是個問題。

當多個任務真正并發執行的時候，等待時間最大化。不管在對內存的利用上還是任務的實時性上都是不利的。公平是效率是矛盾的。

加了優先級就不一樣了，但是優先級不能得到實時反饋的任務信息，需要動態調整的話也不好做。

根子在io。io的不確定性太大。

另外一方面，多線程起源于多道程序設計，多道程序設計也起源于分時。多道程序設計如果不考慮分時的公平性需求的話也是多余的，多個任務可以輪著上，效率更高。但是這個在多個長線程的需求下失效。有些任務是永遠也完成不了的，它們需要分時。特別是操作系統任務，長的不得了。于是分時碉堡了，沒人動得了它。

這就是現在的多任務。

我決定換個角度來考慮，把處理器看成一個主動找活干的人。

歸根結底，只要所有的活都被干了，那么就無所謂活有沒有干完這個問題了。或者，只要處理器已經滿負荷，那么其余的都不是問題。

并且我覺得這個的系統粒度更小一點，所以能提供更細致的任務區分。

線程粒度太粗。

提供更細致的任務區分是建立智能調度的基礎。因為線程沒有辦法被描述。比如一個文件訪問明顯是一個不同的任務，單獨拿出來做可能要好的多。而且不會因為io緩慢阻塞原來的線程形成內存溢出。很多時候io恰恰是一個線程的最大堆棧點。并且一個多階段io的線程將長期占據內存不放。

這個改革將使傳統的編程模型全部實效。J2EE所有的api都將廢棄。J2EE跟線程模型太粘。它是典型的方法調用型計算。加上面向對象，內存很吃虧。多線程跑不動就在這里：io加對象，線程給卡死了。

這個其實也不是大問題。

我覺得只要處理器能動就不是問題。大多數時候并沒有這個問題。

那么為什么還要智能調度呢？

不要。我只是想把多核給真正跑起來。也許小粒度的任務定義能提供更好的并行性能。

關鍵任務之間的關系怎么處理。怎么去掉任務的時序？有兩個問題：一是單任務的劃分，一是多任務的并行。這樣是否意味著一個多級任務模型？這樣就復雜了肯定fail掉。

必須要劃分，否則不可能做到單任務的并行。對線程進行流水線改造。那你又想，為什么線程不行。線程不符合現實情況：現實并發任務并不多。當沒有并發的時候不能充分利用機器的計算能力。

子任務間的依賴將是自適應的：條件沒到就做不了。索性去做別的。

這樣就真正去掉了線程：不允許定義線程。沒有線程。操作系統將全權掌握系統的運行而不只是調度線程。任務退后，系統站出來，像批處理，一切由操作系統說了算。用戶提交的只是真正的“任務”，而不是一個“程序”。

另一方面，分時其實是迫不得已：

處理器被占用時不可能做任何真正的智能調度。因為它沒有周期。

但是多核可以。多核隨時可以動態調度。這樣也迫使將任務降級，使之完全聽命于操作系統而不是只能用個時鐘中斷時不時地看一下優先級動了沒有。

關鍵是任務降級。成為魚腩。是任務是操作系統的魚腩，不是操作系統是線程的魚腩。要奪回操作系統的權利。

去線程化的關鍵則在于強調處理器的第一性地位。讓處理器跳出來，形成一個worker。而不是線程的服用。把它看成是工作的真正完成者而不是線程。讓線程的概念退下，不需要它了。單處理器下必須線程來做到分時，現在不需要了。分時是為了并發，復用，現在自然可以并發復用了。多任務不等于并發。所以分時離開單處理器環境已經沒有用。

另一件關于線程的事就是它嵌入了運行時的語義。操作系統對他能做的就只有做與不做，不可能衍生其它的操作。這個限制了任務的語義發展。比如頂多發展到優先級，進一步則很困難。去掉這個運行時語義它就成了魚腩，基本原因就是這個概念離底層太近。從這個角度還可以看出，線程于系統安全的發展也很不利：它給予程序太多權利。去掉它的運行時特性就給了操作系統空間去做所有的事情：你往你的空間退，你陳述一個任務，我來完成它。這是個理想，我想把系統安全化。安全話最好的方法就是收縮任務的語義，讓他遠離系統。這個就是最小化原則的應用：不讓一個人惹事最好的辦法就是收縮與他的接口。收縮接口就是對他的信任解除。收縮它的相對行為空間！

在系統核心嵌入神經學習網絡，建立評價機制，讓系統自己學習而不是用概率來解決問題。使系統屈從于評價系統。加上規則系統，可以建立一定的智能調度。在任務中加入評價api與數據服務，讓用戶自己產生調度評價。這樣達到以及動態達到最佳調度。可以對系統進行充分的訓練再投入使用也可以讓他在實踐中學習。它將學得非常快并且迅速達到最佳狀態。從這個角度考慮，關鍵要形成正確合理粒度的資源概念。 --這是個理想。

轉載于:https://my.oschina.net/digerl/blog/221398

總結

以上是生活随笔為你收集整理的去线程化与智能调度的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。