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