LabVIEW 是自动多线程语言
一般情况下，运行一个 VI，LabVIEW 至少会在两个线程内运行它：一个界面线程（UI Thread），用于处理界面刷新，用户对控件的操作等等；还有一个执行线程，负责 VI 除界面操作之外的其它工作。LabVIEW 是自动多线程的编程语言，只要 VI 的代码可以并行执行，LabVIEW 就会将它们分配在多个执行线程内同时运行。
图1 是一个正在运行的简单 VI，它由单独一个一直在运行的循环组成。在此情况下，这个执行循环的线程运算负担特别重，其它线程则基本空闲。在单 CPU 计算机上，这个线程将会占用几乎 100% 的 CPU 时间。图1 中的任务管理器是在一个双核 CPU 计算机上截取的。这个循环虽然在每一个时刻只能运行在一个线程上，但这并不表示他始终不变的就固定在一个线程上。他可能在这个时刻运行在这个线程上，另一时刻又被调度到其他线程上去运行了。
因此，图1 这个程序最多只能占用两个 CPU 内核 50% 的总 CPU 时间，两个 CPU 内核各被占用一些。
图1：双核 CPU 计算机执行一个计算繁重的任务
图2 是当程序有两个并行的繁重计算任务时的情况，这时 LabVIEW 会自动把两个任务分配到两个线程中去。这时即便是双核 CPU 也会被 100% 占用。
图2：双核 CPU 计算机执行两个计算繁重的任务
从上面的例子，我们可以得出如下两个结论。
1. 在 LabVIEW 上编写多线程程序非常方便，我们应该充分利用这个优势。一般情况下，编写程序时应当遵循这样的原则：可以同时运行的模块就并排摆放，千万不要用连线，顺序框等方式强制它们依次执行。在并行执行时， LabVIEW 会自动地把它们安排在在不同线程下同时运行，以提高程序的执行速度，节省程序的运行时间。今后多核计算机将成为主流配置，多线程的优势会更为明显。
特殊的情况也是有的，即用多线程时，运行速度反而慢。 以后我们再来详细介绍此类特殊情况。
2. 假如有一个或某几个线程占用了 100% 的 CPU，此时系统对其他线程就会反应迟钝。例如，程序的执行线程占用了100% 的 CPU，那么用户对界面的操作就会迟迟得不到响应，甚至于用户会误认为程序死锁了。所以在程序中要尽量避免出现 100% 占用 CPU 的情况。 目前大多数的计算机还是单核单个 CPU 的，因此要避免任何一个线程试图 100% 占用 CPU 的情况（如图1、图2 所示的程序）。
此类问题最简单的解决方法就是在循环内加一个延时。在图1、图2 的例子中，如果在每个循环内加上 100 毫秒的延时，CPU 占用率就会接近为0。
对于总运行时间较短的循环（假如CPU 占用总时间不足 100毫秒）就没有必要再加延时了。
在很多情况下，运行时间很长的循环往往都只是为了等待某一个任务的完成，在此类循环体的内部几乎没有耗时较多的、又有意义的运算，所以必须在循环框内加延时。
对于那些确实非常耗费 CPU资源 的运算（如需要 100% 地占用 CPU 几秒钟甚至更长的时间），最好也在循环内插入少量延时，从而让 CPU 至少 空出 10% 的时间给其它线程或进程。你的程序会因此而多运行 10% 的时间。 但是由于 CPU 可以及时处理其他线程的需求，比如界面操作等，其他后台程序也不会被打断，用户反而会感觉到程序似乎运行得更加流畅。反之，假如你的程序太霸道了，CPU长期被某些运算所霸占，而别的什么都不能做，这样的程序，用户是不可能满意的。
还有这样一种情况，比如某些运算可能需要程序循环 1,000,000次，每执行一次仅需要 0.1 毫秒。此时如果在每次循环里都插入延时，即使是 1 毫秒的延时，也会令程序速度减慢 10 倍。 这当然是不能容忍的。这种情况下，就不能在每次循环都加延时了，但可以采用每一千次循环后加上 10 毫秒延时的策略。此时，程序仅减慢 10% 左右，而 CPU 也有处理其他工作的时间了。
在处理界面操作的 VI 中，常常会使用到 While 循环内套一个 Event Structure 这种结构形式。在这种情况下，就没有必要再在循环内添加延时了。因为程序在执行到 Event Structure 时，如果没有事件产生，程序不再继续执行下去，而是等待某一事件的发生。这是，运行这段代码的线程会暂时休眠，不占用任何 CPU 资源，一直等到有事件发生，这个线程才会重新被唤醒，继续工作。
评论