# A C-Based Framework for Low-Cost Real-Time Embedded Systems
## 5 Event-Driven Programming
### Hold-Off Interval and Overload Avoidance  
The purpose of the hold-off mechanism is to force the minimum interval between events delivered to the control task to be at least \(t_{h}\), while guaranteeing a bounded maximum event delivery latency, regardless of the rate at which incoming events arrive from remote I/O cards. In the simplest scenario, it operates as depicted in the topmost diagram of Figure 5. Namely, we have the following:  
* At any time the event management task can be in one of two possible states, denoted as _idle_ and _hold-off_ in the figure. The task starts in the idle state.
* When idle, the task immediately sends an event notification to the control task when it receives an event from an I/O card and enters the hold-off state. As an example, the figure shows the arrival of an event from I/O card 1 and its delivery to the control task. The notification sent to the control task contains a set of events that has 1 as its only element.
* The hold-off period lasts for \(t_{h}\), a configurable parameter with a 1 ms granularity. If the event management task receives no further events during the hold-off period, it returns to the idle state without carrying out any further action.  
Figure 5: Hold-off and hold-off extension intervals in event management. The numbers 1, 3, and 5 represent slaves and the events they generate.  
On the contrary, if the task receives one or more events during the hold-off period, as depicted in the middle diagram of Figure 5, it does not immediately send any additional event notification to the control task. Instead, it aggregates all incoming events into a single notification and sends it at the end of the hold-off interval. Then, it starts the hold-off interval again, thus repeating the process. For instance, if events originating from slaves 1, 3, and 5 arrive during a hold-off interval, the event management task will send a single notification to the control module at the end of the interval. The notification will contain the set of events \(\{1,3,5\}\).  
Overall, the hold-off mechanism guarantees that events arriving while the task is idle reach the control task as soon as possible. At the same time, it also guarantees that events arriving during a hold-off interval are serviced after at most \(t_{h}\), while keeping the minimum interval between consecutive control task activations also at \(t_{h}\). To do this, the hold-off mechanism breaks the one-to-one relationship between events received from the I/O cards and notifications sent to the control task. Namely, multiple events arriving in quick succession will be gathered and result in a single notification being sent.  
Moreover, an overload avoidance mechanism, also implemented by the event management task, may delay the generation of further notification events towards the control task, by extending the hold-off interval, if the control task has not completely processed the previous event yet. An example of this mechanism is illustrated in the bottom diagram of Figure 5. It shows how, after initially delivering event set \(\{1\}\) to the control task, the event management task kept extending the hold-off interval by \(t_{e}\) until it received an end-of-service notification from the control task. During a hold-off extension, the event management task handles incoming events as in a normal hold-off interval. Like \(t_{h}\), \(t_{e}\) is a configurable RTFW parameter with 1 ms resolution.