The host/client design pattern consists of multiple parallel loops executing tasks at different rates. One loop, the host, controls one or more other loops, the clients, and communicates with them using a messaging architecture. In the EV3 Software, we can use variables to send messages between loops.
In the following example, the host loop uses a logic variable called "flag" to instruct the client loop to turn a motor on or off. We use a logic variable because we only have two states, on and off, but we could use another type of variable if we needed to have more than two states.
To implement a basic host/client design pattern in the EV3 Software, we need at least two loops - the host (or main program) loop and the client loop - and a variable controlled by the main program in the host loop that tells the client loop when to fire an action or a condition.
In the above example, the host loop changes the value of the flag when the touch sensor is pressed to turn the motor on or off in the client loop.
Note that the host loop can contain several split sequences to control different processes that will occur at the same time. In such case we should take care to avoid a race condition that could occur when different parts of the host loop program try to set the client loop variable at the same time.
In LabVIEW, instead of variables we can use flags which are global indicators that can be read or set to true or false from anywhere in your code. Flags have many applications such as triggering certain code to run when a sensor input is read or enabling different subprocesses in your code to signal to each other. Flags are not implemented in EV3 but we can use variables for the same purpose, and this is why we have called the variable "flag" in this example.
The host/client design pattern is a fundamental architecture used in LabVIEW (the software that the EV3 Software is based on) when you have two or more processes that need to run simultaneously and continuously but at different rates. If these processes run in a single loop, how would you control the fact that one part of the loop might take longer to execute than another? If this happens the remaining sections (or split sequence beams of the loop) will get delayed before executing the next iteration.
Another programming architecture, the state machine design pattern, is described in the post From Sequential Programming to State Machine.
.svg){kind=icon}
