In a centralized control model, one component is designated as the controller and is responsible for managing the execution of other components. Centralized control models fall into two classes, depending on whether the controlled components execute sequentially or in parallel.
The call–return model is illustrated in Figure 1. The main program can call Routines 1, 2 and 3; Routine 1 can call Routines 1.2 or 1.2; Routine 3 can call Routines 3.1 or 3.2; and so on. This is a model of the program dynamics. It is not a structural model; there is no need for Routine 1.1, for example, to be part of Routine 1.
Figure 1 A call-return control model
This familiar model is embedded in programming languages such as C, Ada and Pascal. Control passes from a higher-level routine in the hierarchy to a lower-level routine. It then returns to the point where the routine was called. The currently executing subroutine has responsibility for control and can either call other routines or return control to its parent. It is poor programming style to return to some other point in the program.
This call–return model may be used at the module level to control functions or objects. Subroutines in a programming language that are called by other subroutines are naturally functional. However, in many object-oriented systems, operations on objects (methods) are implemented as procedures or functions. For example, when a Java object requests a service from another object, it does so by calling an associated method.
The rigid and restricted nature of this model is both a strength and a weakness. It is a strength because it is relatively simple to analyse control flows and work out how the system will respond to particular inputs. It is a weakness because exceptions to normal operation are awkward to handle.
Figure 2 is an illustration of a centralised management model of control for a concurrent system. This model is often used in ‘soft’ real-time systems which do not have very tight time constraints. The central controller manages the execution of a set of processes associated with sensors and actuators. The building monitoring system discussed in Chapter 20 uses this model of control.
Figure 2 A centralized control model for a real-time system
The system controller process decides when processes should be started or stopped depending on system state variables. It checks if other processes have produced information to be processed or to pass information to them for processing. The controller usually loops continuously, polling sensors and other processes for events or state changes. For this reason, this model is sometimes called an event-loop model.