labview主从设计模式和生产者消费者设计模式.docx
《labview主从设计模式和生产者消费者设计模式.docx》由会员分享，可在线阅读，更多相关《labview主从设计模式和生产者消费者设计模式.docx（15页珍藏版）》请在冰豆网上搜索。
labview主从设计模式和生产者消费者设计模式
5.2LabVIEW设计模式——主／从设计模式和生产者／消费者设计模式
在上一节中曾经谈到过，NILabVIEW中提供了六种最基本的设计模式。
本节首先介绍其中的两种：
主／从设计模式与生产者／消费者设计模式（Master/SlavedesignpatternandProducer/Consumerdesignpattern）。
这是由于这两种设计模式在结构上极为相似（使用的内置函数不同），所以我们在这里将一起来讨论（基本结构参见图5.2-1、图5.2-2）。
图5.2-1主／从设计模式
图5.2-2生产者／消费者设计模式
5.2.1主／从设计模式（Master/Slavedesignpattern）
与主／从设计模式的相关内置函数（Notifier_通知）参见下图所示。
图5.2.1-1主／从设计模式内置函数（通知）
关于这些内置函数的定义和使用方法请参考LabVIEWHelp文件，这里就不再进行讨论了。
对于绝大多数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内置函数的设计者，所以不清楚主／从设计模式的数据存储方式，所以我们只能认定：
这种工作方式当SendNotification有效时，元素被存储，当WaitonNotification有效时，元素被读取，从而实现主／从结构间的数据传递。
这样做就会高枕无忧了吗？
其实不然！
这种构架的缺点是：
如果取走元素的速度慢，而发送元素的速度快，則会发生元素漏掉的情形。
为了验证这样的说法，我们做一个简单的验证程序。
例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/Consumerdesignpattern）
可以说：
生产者、消费者设计模式是图形化程序设计中最广泛使用的设计模式。
与生产者、消费者设计模式的相关内置函数（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-6Mac电脑用于数据采集的生产者／消费者例程（DAQmxBase）
通过这个例程可以参考错误处理方式的使用方法以及数据采集如何使用生产者／消费者模式和队列大小的监视（千万不要撑暴了FIFO）。
其实，生产者／消费者模式不仅用于数据采集处理，早期还用于GUI响应（基于队列）。
由于事件驱动设计模式的出现，现在大多数GUI响应都是通过事件处理机制来实现了。
下一单元，我们就来介绍事件处理机制。
升级会员 