Editing LabVIEW (section)

== Common application design patterns ==
Applications in LabVIEW are typically designed using well-known architectures{{citation needed|date=November 2021}} known as [[design pattern]]s. The most common design patterns for graphical LabVIEW applications are listed in the table below.
{| class="wikitable"
|+Common design patterns for LabVIEW applications
!Design pattern
!Purpose
!Implementation details
!Use cases
!Limitations
|-
|Functional Global Variable
|Exchange information without using global variables
|A shift register of a [[while loop]] is used to store the data and the while loop runs only one iteration in a "non-reentrant" virtual instrument (VI)
|Exchange information with less wiring
|All owning virtual instruments (VIs) are kept in memory.
|-
|State machine<ref>{{cite web |url=http://www.ni.com/white-paper/3024/en/ |title=Application Design Patterns: State Machines |date=8 September 2011 |website=National Instruments whitepapers |accessdate=21 September 2017 |url-status=live |archiveurl= https://web.archive.org/web/20170922002635/http://www.ni.com/white-paper/3024/en/ |archivedate=22 September 2017}}</ref>
|Controlled execution that depends on past events
|[[Switch statement|Case structure]] inside a while loop passes an [[Enumerated type|enumerated variable]] to a shift register, representing the next state; complex state machines can be designed using the Statechart module
|User interfaces,
complex logic, 
communication protocols
|All possible states must be known in advance.
|-
|Event-driven user interface
|Lossless processing of user actions
|GUI events are captured by an event structure queue, inside a while loop; the while loop is suspended by the event structure and resumes only when the desired events are captured
|Graphical user interface
|Only one event structure in a loop.
|-
|Master-slave<ref>{{cite web |url=http://www.ni.com/white-paper/3022/en/ |title=Application Design Patterns: Master/Slave |date=7 October 2015 |website=National Instruments whitepapers |accessdate=21 September 2017 |url-status=live |archiveurl= https://web.archive.org/web/20170922002540/http://www.ni.com/white-paper/3022/en/ |archivedate=22 September 2017 }}</ref>
|Run independent processes simultaneously
|Several parallel while loops, one of which functions as the "master", controlling the "slave" loops
|A simple GUI for data acquisition and visualization
|Attention to and prevention of [[race condition]]s is required.
|-
|Producer-consumer<ref>{{cite web |url=http://www.ni.com/white-paper/3023/en/ |title=Application Design Patterns: Producer/Consumer |author=<!--Not stated--> |date=24 August 2016 |website=National Instruments whitepapers |access-date=21 September 2017 |url-status=live |archive-url=https://web.archive.org/web/20170922002635/http://www.ni.com/white-paper/3023/en/ |archive-date=22 September 2017 }}</ref>
|Asynchronous or multithreaded execution of loops
|A master loop controls the execution of two slave loops, that communicate using notifiers, queues and semaphores; data-independent loops are automatically executed in separate threads
|Data sampling and visualization
|Order of execution is not obvious to control.
|-
|Queued state machine with event-driven producer-consumer
|Highly responsive user-interface for multithreaded applications
|An event-driven user interface is placed inside the producer loop and a state machine is placed inside the consumer loop, communicating using queues between themselves and other parallel VIs
|Complex applications
|
|}