程序原本(八十九):系统的基础部件——依赖(在逻辑 / 数据时序依赖之间转换的基本方法)

阅读数:24 2019 年 10 月 5 日 13:42

程序原本(八十九):系统的基础部件——依赖(在逻辑/数据时序依赖之间转换的基本方法)

我们提到过“(逻辑或数据的)时序依赖”,是在时间维度下不可分解的。这意味着某些逻辑不可分布,而另一些情况下,某些数据也不可分布。对于后者,我们讨论了一种可能的、与处理逻辑相关的解:数据不可分布时通常会使逻辑趋向于复杂,例如需“判断 100M 数据的边界上是否存在换行”等。但这样的思路让我们陷入了困局:对于逻辑的时序依赖,那么又是否有解呢?

“挖坑、栽树”是一个(典型的、纯粹的、逻辑的)时序依赖活动。首先,这个系统中涉及的“坑”与“树”是不同的数据,相互间没有必然的依赖关系。其次,我们的的确确无法在时序上把它的逻辑倒置过来:无论是一个人来做,还是一群人来做这件事情,总得等挖完坑后才能栽树,这时多个团队或者 CPU 的多核并没有起到作用。

但注意一个细节 :只有当我们将“挖坑、栽树”过程理解为“在位置 A上挖坑,并在位置 A上种树”时,“位置 A”才是这两个步骤的数据依赖。一旦去掉这个数据依赖,“挖坑”与“栽树”这两个行为本质上其实是没有依赖的,例如在“在位置 A上挖坑,并在位置 B上种树”就变得可行了。

这带来一个有趣的结论:我们(也许)1总是可以通过添加一层数据抽象,来将“逻辑的”时序依赖,变成“数据的”时序依赖。例如我们此前提到的:

1 很遗憾我无法证实这一点,但就目前的实践来说,这总是成立的。

  • 函数 B 用于计算函数 A 的执行时长,则函数 B 必须在函数 A 逻辑结束之后执行,

就可以理解为:

  • 设有时间戳 X,函数 B 修改该时间戳,而函数 A 统计该时间戳的修改。

两个逻辑作用于同一个数据(无论它们分别拿该数据来做何种处理),这是一个明显的特性。当这种特性存在时,我们称该数据是多个逻辑的数据依赖2。仅当我们能够通过对数据依赖的分析(而非对动态的逻辑执行结果的分析)就能确立这种依赖时,我们才可以自动化地分布与协调这些分布。

2 我们已经提到多个与“依赖”相关的概念。若我们只是单独使用“依赖”,则表明它是自然语言中的、表明多个事或物之间存有依存关系的含义。当我们使用“时序依赖”时,它是包括逻辑的数据的时序依赖两种情况。当我们使用“数据依赖”时,我们是用这个概念来统一了上述两种时序依赖。

换言之,分布方式的确立以及在多个分布逻辑之间的协调等问题,都可以转化为对数据依赖的处理。再综合我们此前讨论的“数据的不可分布能够通过复杂的逻辑来解决”,最终可以得出这样一个结论:逻辑的不可分布并非无解,它最终可以被聚焦于“用于处理数据依赖问题的逻辑”的复杂性。

评论

发布