再次回顧“基本狀態機模式”的6個缺點，只剩下第6個缺點無法在上述的“狀態機和事件結構的結合模式”中被解決。

1. 任何時刻只能有一個狀態在運行

這個問題也許有些多余，但是在實際的應用中往往又是最常見的。大多數比較復雜的應用至少應該有“菜單”和“采集”兩個狀態，如果數據采集程序在運行時仍然希望系統能夠處理菜單的事件，這是在傳統的狀態機或者事件結構中無法實現的。因為無論是狀態機結構還是事件結構，都是由一個循環組成的，不同的狀態是無法同時被響應和處理的。
解決這個問題的方式也比較簡單，LabVIEW本身就是一種多線程的程序設計語言，可以再加一個循環或者另外開一個程序獨立運行。但是這樣也會帶來一些新的問題，比如：

1. 兩個循環（程序）之間如何交換和共享數據。
2. 兩個循環（程序）都有著獨立的錯誤處理系統，它們之間是如何協調的。
3. 兩個循環如何分工呢？應該以哪種方式對狀態進行分類以將不同的狀態放置在不同的循環（程序）中？
4. 一個程序如何控制另一個程序的運行和停止。

在上面提出的4個問題中，對循環和程序這兩個解決方案而言，第（1）~（3）個問題的解決方式是一樣的。只有第（4）個問題是專門針對兩個程序而言的，在LabVIEW中這種不同程序之間的相互調用稱為“程序的動態調用”。