labview主／从设计模式和生产者／消费者设计模式.docx

5.2 LabVIEW设计模式主从设计模式和生产者消费者设计模式 在上一节中曾经谈到过，NI LabVIEW 中提供了六种最基本的设计模式。本节首先介绍其中的两种： 主从设计模式与生产者消费者设计模式（Master/Slave design pattern and Producer/Consumer design pattern）。这是由于这两种设计模式在结构上极为相似（使用的内置函数不同），所以我们在这里将一起来讨论（基本结构参见图 5.2-1、图 5.2-2）。 图 5.2-1 主从设计模式 图 5.2-2 生产者消费者设计模式5.2.1 主从设计模式（Master/Slave design pattern） 与主从设计模式的相关内置函数（Notifier_通知）参见下图所示。 图 5.2.1-1 主从设计模式内置函数（通知） 关于这些内置函数的定义和使用方法请参考LabVIEW Help文件，这里就不再进行讨论了。 对于绝大多数LabVIEW的学习者来讲，仅仅依据这些主从操作提供的内置函数（通知），即便是借助于帮助文件也很难理解和设计出正确的应用程序代码或基本架构。因为 这些内置函数的内部程序代码是不对外开放的、不公开的，所以我们也就很难理解的更准确或更全面。 那么如何正确的使用它们呢？ 通常有两个最简单、最直接的方法可以解决这个问题：一是，查看NI给出的设计模式或例程；二是，查看其它使用者所提供的实用例程。 其实，这里也再次间接的告诉大家，更多查看和理解其它LabVIEW开好者所提供的实用例程是学习LabVIEW的最好方法之一。 通过图 5.2-1，就可以初略地领会到NI 基于数据流的图形化代码主从设计模式的表达形式或架构。 从图 5.2-1中，可以看到主从设计模式的基本构成是：包括了两个While循环（上面为主循环、下面的为从循环）和若干个“通知”内置函数（Notifier）构成。主 循环中的Case结构用来确定是否向从循环发出通知。 该设计模式支持图形化代码的多种数据类型的数据输入（图 5.2-1中的数据类型为：字符串）；并且用一个Stop按键来控制这两个While循环的停止。 如果用“高亮执行”方式来查看它的数据流运行状态时，我们会发现：当主循环中的Case结构的条件输入端为：F时，主循环不会发出通知，从循环也不执行任何操作； 当主循环中的Case结构的条件输入端为：T时，主循环发出通知，从循环执行相应的操作。当我们按下“Stop”键时，主循环停止并利用错误簇（表现为：出现错误）通知 从循环也停止。 主从设计模式工作时，数据（元素）传递是发生在两个While之间，依据While循环的数据流工作原理，我们的确很难理解数据是如何在两个While循环之间传递的 。这使得这种结构的两个While循环之间传递数据的关系看起来有点象全局变量（或本地变量）。 其实，它与全局变量功能上是相近的，但还是有些区别。其中最主要区别在于：负责产生信息的主循环必须保持循环查询数据是否发生变化。在数据没有发生改变的时候，从循环结 构则完全停止执行，只有当新数据可用时才重新启动（通知）。这就会使计算机减少浪费在无止境的轮询中的时间。另外，全局变量破坏了数据流的关系，而这里则完全保证了数据流 的关系。 主从设计模式主要用来解决两个或多于两个的同时发生的并且拥有不同运行速率的线程的通信应用中或者在运行于同一台机器的两个VI之间通信的工具。这种方式一般用来同步 两个独立的进程，所以它的这些内置函数是分类在函数选板的同步模版中。 其实，在数据采集和处理中，更需要这种主从构架的应用。比如，在连续数据采集和分析、处理中，我们可能会将采集、分析、处理放在一个While循环内。那么While 循环运行一次的时间就是采集、分析、处理这三部分运行时间之和。如果任务中需要快速采集和实时处理，显然这种在采集、分析、处理同放在一个While循环中的方式很不好， 很可能导致数据采集的不连续性（数据时间上出现间断点），也就是采集完后将等待分析、处理完成后才能再次进行采集。 如果真的不希望这种情况发生，那就可以通过采用主从设计模式来解决这样类似的问题。比如，将数据采集放到主循环中，分析和处理放置到从循环中。 由于我们不是LabVIEW内置函数的设计者，所以不清楚主从设计模式的数据存储方式，所以我们只能认定：这种工作方式当Send Notification有效时，元素被存储，当Wait on Notification有效时，元素被读取，从而实现主从结构间的数据传递。 这样做就会高枕无忧了吗？其实不然！ 这种构架的缺点是：如果取走元素的速度慢，而发送元素的速度快，則会发生元素漏掉的情形。 为了验证这样的说法，我们做一个简单的验证程序。例 5.2.1-1 主从结构数据传递试验 图5.2.1-2 是该程序的程序框图。 图 5.2.1-2 主从模式数据传输试验程序框图 主循环产生一个随机数并发送到从循环，在每个循环中各放置一个Chat图形显示器来观察随机数发送和接收的情况。主从循环各放置一个定时器，选择不同的定时时间来验证 数据传输的正确性。1、主循环定时：150ms，从循环定时：150ms 图 5.2.1-3 主循环、从循环定时均为150ms 从图 5.2.1-3可以看出数据传递是准确可靠的。2、主循环定时：200ms，从循环定时：150ms 图 5.2.1-4 主循环定时200ms、从循环定时为150ms 从图 5.2.1-4也可以看出数据传递是准确可靠的。3、主循环定时：150ms，从循环定时：200ms 图 5.2.1-5 主循环定时150ms、从循环定时为200ms 从图 5.2.1-5可以看出数据传递明显出现丢失数据的现象。数据没有传递完是由于我们终止了运行。 还有一个问题，从循环的停止是来自于主循环提供的错误信息，那么如果从循环内发生错误如何报错？ 鉴于这些原因存在，这也是主从循环设计模式被使用的比较少的原因之一。那么有没有更好的解决方法呢？这就是我们下节所要介绍的“生产者、消费者设计模式”。5.2.2 生产者消费者设计模式（Producer/Consumer design pattern） 可以说：生产者、消费者设计模式是图形化程序设计中最广泛使用的设计模式。 与生产者、消费者设计模式的相关内置函数（Queue_队列）参见下图所示。 图 5.2.2-1 生产者消费者设计模式内置函数（队列） 在图 5.2-2中，就是基于数据流的图形化代码生产者消费者设计模式的表达形式或架构。 它的构成与上面所讨论的主从设计模式基本相同，只是使用的内置函数不同。同样我们也不介绍内置函数的定义和使用方式。同时，生产者消费者设计模式的基本工作原理也就 不多介绍了。 下面主要介绍它们之间的不同之处。 它们之间最大的不同就是数据存储和传输方式的不同。生产者消费者设计模式采用了队列的数据存储方式（FIFO）。队列的数据存储是开辟一个缓存区，依据先进先出的原则 进行的。新来的元素总是被加入队尾（即不允许加塞），每次离开的元素总是队列头上的（即不允许中途离队），当前最老的元素离队。这样就保证了数据传递过程中基本上 不会发生数据丢失的现象。 为了验证这样的说法，我们还是同样做一个简单的验证程序。例 5.2.2-1 生产者消费者结构数据传递试验 图5.2.2-2 是该程序的程序框图。 图 5.2.2-2 生产者消费者模式数据传输试验 生产者循环产生一个随机数并发送到消费者循环，在每个循环中各放置一个Chat图形显示器来观察随机数发送和接收的情况。生产者消费者循环各放置一个定时器，选择不同 的定时时间来验证数据传输的正确性。1、生产者循环定时：150ms，消费者循环定时：150ms 图 5.2.2-3 生产者循环、消费者循环定时均为150ms 从图 5.2.2-3可以看出数据传递是准确可靠的。2、生产者循环定时：200ms，消费者循环定时：150ms 图 5.2.2-4 生产者循环定时200ms、消费者循环定时为150ms 从图 5.2.2-4可以看出数据传递也是准确可靠的。3、生产者循环定时：150ms，消费者循环定时：200ms 图 5.2.2-5 主循环定时150ms、从循环定时为200ms 从图 5.2.2-5 可以看出数据传递也没有出现数据丢失的现象。实际上，由于数据传递被强行停止，所以后面的数据没有被全部完全传递出来。解决这个问题的方法是在程序设计中添加一些处理程 序，这部分内容可参考：LabVIEW网络讲坛系列第三季运筹帷幄生产者/消费者循环。 还是那个问题，从循环的停止是来自于主循环提供的错误信息，从循环内如果发生错误如何报错？ 下面给出一个使用Mac版LabVIEW编写的DAQmxBase的实例（仅用于Mac数据采集应用）。 图 5.2.2-6