討論:行程

進程就是正在運行的程序。 這樣定義比較好理解。 --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)