[发明专利]一致地信令状态变更

说明书

背景

在计算机化系统内使用的应用程序通常包括出于各种不同的原因而相互依赖的多个不同的组件或模块。例如，简单的计算器应用程序可以包括输出显示组件，该输出显示组件在它标识到从计算模块输出的一个或多个值的任何时刻立即刷新(即，显示新输出)。计算模块进而可被配置成在它接收到来自一个或多个输入组件的一个或多个数字和函数输入的任何时刻执行计算。由此，显示组件将不仅依赖于计算模块，而且还最终依赖于计算器应用程序中的各个输入组件中的每一个。

存在可在软件级配置这些依赖关系的多种不同的方式。例如，上文所描述的计算器模块可以“发布”其计算出的值，以使得正在“监听”该值的任何其他显示组件将在值被发布时标识该值并对其执行某一动作。为标识何时发布值，显示组件进而可以建立监听程序(例如，建立“事件”)，该监听程序最终标识和/或接收已发布的值。在其他情况下，计算器模块本身可以被配置成将任何新计算出的值传递(例如，“信令”)给向计算器模块注册的特定其他组件。由此，可以理解，存在用于将数据从一个软件组件传递到另一个软件组件的多种“推”和“拉”样式的机制。

由此，在程序员想要创建模块或组件之间的依赖关系的任何时刻，程序员通常将需要在代码中编写依赖关系，并且有时甚至为该关系创建监听程序。例如，程序员可以编写一个监听程序，该监听程序不仅在一个组件发布值时检索该值，而且还将该值发送到依赖关系链中的另一个组件。程序员也可以或另选地编写其他逻辑，由此组件只在满足了某种特定条件时(例如，值具有特定大小)向上发送值。结果，可以理解，组件链中的每一监听程序都可以按不同的方式，并以不同的速度来处理值。

尽管将逻辑写入到每一监听程序中的能力可以提供某种编程灵活性，但是，它也将会导致过分复杂的依赖关系链，和/或难以保证其准确性。例如，复杂依赖关系链会具有许多不同的监听程序，每一监听程序都有效地以不同的方式，并以不同速率来响应一个或多个源节点中的相同变更。这会导致依赖关系链中的后续组件的竞争条件。具体而言，依赖于从同一个源接收到值的两个组件的依赖子组件最终可以处理来自一个父组件的已正确地更新的值，但是，使用过时的值来再次执行。或者，依赖子组件最终可能由于很有可能永远不会发生的条件而无限地挂起。这可能沿着依赖关系链具有更进一步的连锁反应。

除前面的内容之外，在常规系统的情况下，甚至可以在用于接收信息的更直接的路线可能是优选的情况下使用软件组件之间的相同依赖关系。例如，一个依赖关系链可能涉及从源节点A，到中间节点C，然后到最终节点D的依赖关系。然而，在其他情况下，节点A可能只需要来自最终节点D的值。例如，在第二执行上下文中，最终节点D可能只需知道源节点A已经变更，而不一定立即需要源节点A的值。在大多数情况下，甚至第二执行上下文仍将涉及将变更的实际值从A中继到C到D，即使D只需知道A已经变更。在较长的依赖关系链中，特别是涉及若干不同条件的依赖关系链，仅仅对于最终节点D发现源节点A已经变更将会有较大的、不必要的延迟。

用于克服这些问题的某些常规机制涉及简单地将频繁刷新速率编码到不同的监听程序中的每一个中。虽然在某些情况下有效，但是，可以理解，这在计算上是昂贵的且没有必要，特别是在可能涉及大量监听程序的情况下。例如，依赖关系链中的某些底层源组件可以经常变更，而其他底层组件可能很少或不经常变更。此外，某些其他组件甚至可能不在特定输出中涉及，并因此费力地传递(并计算)这些最终节点处的值将尤其没有必要。例如，电子表格上的只表示最终值但是由于某种原因当前没有显示在显示屏幕上的单元格，可能直到这些单元格在视图内才需要更新。

因此，均码(one-size fits all)方法通常可以是不必要的。此外，在当前的系统中往往充斥着低效，因为常常有依赖关系被注册两次的情况，还因为很少有上游监听程序一定在其他下游监听程序之前处理某些数据的保证。尽管这些类型的问题可能对于少数不经常变更的组件不成问题，但是，这些类型的问题可能不必要地减缓或挂起具有大量不断变更的显示的数据(例如，处理股票行情数据)的系统。此外，这样的问题还可能导致无响应组件，或其他不必要的处理延迟。

因此，存在可以解决的与报告复杂软件依赖关系中的值变更相关联的多个困难。

简要概述