討論:行程
![]() |
行程屬於維基百科科技主題的基礎條目第五級。請勇於更新頁面以及改進條目。 本條目頁屬於下列維基專題範疇: |
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
進程就是正在運行的程序。 這樣定義比較好理解。 --river
- 行程就是正在行進的程式,所以其實沒差。
慘不忍睹
編輯加了一些內容。不過執行緒條目竟然只是重新導向到Thread,而且還是空頁面,行程一整個條目幾乎沒什麼內容可言.....--Hiaeoupyc 2007年5月18日 (五) 06:47 (UTC)
程式、程序 和 執行緒
編輯事實上,程式 和 程序 指代的是兩個完全不同的事物,前者 重於 其形式 (program(me)),像是數學公式一樣的事物,於是羅列或記在紙張或記憶體以外的代碼均可用 程式 指代。而 程序 其詞重於 序,佇列中的排序,代碼之間的序 只存在於 邏輯 或 正在運轉於CPU的代碼之中,因此它所指代的 正好是 英文詞的 process,即本條目。台灣微軟公司 將 program 譯作 程式,而process 譯作 處理程序。 執行期間控制CPU運轉的的代碼,如同編織時 穿針引線 的 線,於是 英文字 thread用以表徵這一事物,而且 對應中文字 緒,比如思緒,除了線體以外表達出其複雜的感性,因此 執行緒 ……—以上未簽名的留言由119.53.116.138(對話)於2017年9月2日 (六) 08:21 (UTC)加入。
存在多個問題
編輯關於 program 的順序,存在至少兩類不同的內涵。一方面是 program 自身代碼表達上的,另一方面是關乎 program 表達的計算運行時的行為的(考慮到作為輸入被消耗,這種運行通常被稱為執行(execution))。順序的表達只是 program 一種表面的——輸入格式上能被文法(grammar) 簡單概括的、純語法(syntax) 方面的——實現方式。而描述順序執行,通常的語法無能為力,需要用語義模型定義。
事實是,program 在一般意義上並沒有限定表達的規則,於是不會要求具體文法是否需要蘊含順序語法。使用幾種不同時期流行的語言,就容易看出不少出入。例如,一般的機器碼就是二進制串,沒有順序語法規則;為了表達順序執行的語義,則通常會在模型中隱含一個 program counter ,在默認情況下表現執行時狀態的順序。用其它語言就未必是這樣。BASIC 這樣的語言就強調「語句」作為語法元素的順序,來對應描述的默認執行順序。但這種使字面上的語法順序和執行順序的做法越來越過氣,傳統上就只有一些強調 imperative paradigm 的語言會買賬,而現代典型的 imperative 設計有意無意地把整體有序迴避了(反而經常是在每個 translation unit 要求區分出 top-level structure ,無視表達順序而更加地所謂「結構化」——儘管「結構化」原意只是表達指令式「控制流」的術語)。
這個背景下,可以確認大多數語言都不要求表達的順序和執行順序一致,甚至整體上被迴避。於是不論是為了簡化執行順序的描述,還是僅僅作為一種「書寫規範」,表達的順序都算不上是有多少通用性的性質。
而關於執行順序的方面,一個事實是,高級(結構化)語言中的所謂順序構造,原則上都不需要基本的(primitive) 。操作語義上,首先定義出 redex 的規約順序或者簡化的表達式的求值順序,於是這種所謂的執行順序是能以從表達式基礎上構造的、通過應用序的函數調用(applicative function call) 和單子(monad) (對應公理語義的函數應用規約規則和結合律)之類的方式派生組合明確表達的行為性質。而純聲明式的語義(例如強制排除任何對順序敏感的副作用的純函數式風格)甚至可以做到使執行的行為僅依賴 program 中包含的值的計算,而無視任意計算之間順序差異的影響。(順便,傳統上所謂的「數學公式」正是僅限純函數式的一種表達;而語義模型中使用的 TRS 等 deduction system ,則是能夠描述完整的計算和推理的現代數學意義上的完全體;傳統數學公式只是後者中的一小部分。)於是,執行上的順序,也不是普遍上總是需要關注的基本性質。
所以,在一般意義上,以上無論哪類順序,都不是足夠普遍的:定義不出對任何 program 的實例都有意義的「順序」性質。是否存在「順序」,一般沒有必要先行區分而被強調。這樣,所謂的程式和程序在關於「順序」的差異的內涵上是一回事;至於用哪個就看習慣了。
倒是所謂的 thread (of execution) 同時在內部默認隱含了的兩類順序(正如 BASIC 那樣),但其實算是被濫用了。所謂的 thread ,本來就只是 CPU 廠商發明的被表達被順序處理的硬件支持解釋的代碼構造,在高級語言嚴格意義上都不存在,只是通過新增的抽象(典型地,POSIX thread )縫合上去罷了。用戶空間所謂叫做 thread 的東西,本來就是 process calculi 之類的模型中所謂的 process ;在同時存在所謂的 thread 和 process 的整體實現(如 Windows NT )上,process 又被強加上地址空間隔離這種語義和任務管理的實現細節。在另一方面,要求在這裏區分兩者的實現細節,也給作業系統的多任務設計帶來本不必要的限制。Linus Torvalds 在這方面就有一個具體的論述,詳細解釋為什麼 Linux 內核不這樣設計。
在英文就普遍存在這類認知偏差的背景上,糾結 process/thread 的翻譯的意義如何,屬實雞肋。
另外,不管怎麼說,還是要注意一下歷史的行程。-- 幻の上帝(留言) 2021年8月16日 (一) 18:52 (UTC)