两个结论。
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 资源，一直等到有事件发生，这个线程才会重新被唤醒，继续工作。
此外，将文件保存成LLB文件或许更好些：
http://digital.ni.com/public.nsf/allkb/F780D7A14550476886257551000BA7D3具体的实现方法。