Talk:行程
![]() |
行程属于维基百科科技主题的基礎條目第五級。请勇于更新页面以及改進條目。 本条目页属于下列维基专题范畴: |
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
进程就是正在运行的程序。 这样定义比较好理解。 --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)