LabVIEW——北方客栈

2011年10月21日，第二稿

    主／从设计模式设计模式（Master/Slave design pattern）与我们前面所介绍的生产者／消费者设计模式在程序架构上有些相似，只是使用的内置函数不同。当然，这也导致它们的运行机理也会不同。

    获得主／从设计模式的方法很简单，在LabVIEW启动界面选择：
》新建（更多...）
》VI
》基于模板
》框架
》设计模式
》用户界面事件处理器
参见下图。

    用鼠标双击上图中的“主／从设计模式，就会得到图形化的主／从设计模式模板，参见下图。

    从图 9－46中，可以看到主／从设计模式的基本构成：包括了两个While循环（上面为主循环、下面的为从循环）和若干个“通知”内置函数（Notifier）构成。主循环中的Case结构用来确定是否向从循环发出通知。

    该设计模式支持图形化代码的多种数据类型的数据输入（图 9－46中的数据类型为：字符串）；并且用一个Stop按键来控制这两个While循环的停止。

    如果用“高亮执行”方式来查看它的数据流运行状态时，我们会发现：当主循环中的Case结构的条件输入端为：F时，主循环不会发出通知，从循环也不执行任何操作； 当主循环中的Case结构的条件输入端为：T时，主循环发出通知，从循环执行相应的操作。当我们按下“Stop”键时，主循环停止并利用错误簇（表现为：出现错误）通知从循环也停止。

    主／从设计模式工作时，数据（元素）传递是发生在两个While之间，依据While循环的数据流工作原理，我们的确很难理解数据是如何在两个While循环之间传递的。这使得这种结构的两个While循环之间传递数据的关系看起来有点象全局变量（或局部变量）。

    其实，它与全局变量功能上是相近的，但还是有些区别。其中最主要区别在于：负责产生信息的主循环必须保持循环查询数据是否发生变化。在数据没有发生改变的时候，从循环结构则完全停止执行，只有当新数据可用时才重新启动（通知）。这就会使计算机减少浪费在无止境的轮询中的时间。另外，全局变量破坏了数据流的关系，而这里则完全保证了数据流的关系。

    主／从设计模式主要用来解决两个或多于两个的同时发生的并且拥有不同运行速率的线程的通信应用中或者在运行于同一台机器的两个VI之间通信的工具。这种方式一般用来同步两个独立的进程，所以它的这些内置函数是分类在函数选板的同步模版中。

    其实，在数据采集和处理中，往往更需要这种主／从构架的应用。比如，通常的连续数据采集和分析、处理中，我们可能会将采集、分析、处理放在一个While循环内。那么While循环运行一次的时间就是采集、分析、处理这三部分运行时间之和。如果任务中需要快速采集和实时处理，显然这种在采集、分析、处理同放在一个While循环中的方式并很不好，很可能导致数据采集的不连续性（数据时间上出现间断点），也就是采集完后将等待分析、处理完成后才能再次进行采集。

    如果真的不希望这种情况发生，那就可以通过采用主／从设计模式来解决这样类似的问题。比如，将数据采集放到主循环中，分析和处理放置到从循环中。

    这样做就会高枕无忧了吗？其实不然！

    这种构架的缺点是：如果取走元素的速度慢，而发送元素的速度快，則会发生元素漏掉的情形。

    为了验证这样的说法，我们做一个简单的验证程序。

例 9.7.2-1 主／从模式数据传递试验

图 9－47是该程序的程序框图。
    主循环产生一个随机数并发送到从循环，在每个循环中各放置一个Chat图形显示器来观察随机数发送和接收的情况。主／从循环各放置一个定时器，选择不同的定时时间来验证数据传输的正确性。

1、主循环定时：150ms，从循环定时：150ms

    从图 9－48中可以看出数据传递是准确可靠的。

2、主循环定时：150ms，从循环定时：200ms

    从图 9-48中可以看出数据传递明显出现丢失数据的现象（数据不一致）。数据没有传递完是由于我们终止了运行。

    还有一个问题，从循环的停止是来自于主循环提供的错误信息，那么如果从循环内发生错误如何报错？

    鉴于这些问题存在，这也是主／从循环设计模式很少被使用与数据传递的主要原因之一。这种方式比较适合于同步处理方式的启动，对于数据传递最好使用“生产者、消费者设计模式”。