In the table it can be seen that module M
1 has given its notification after 10 time units and the other modules after 9 time units. In view of the notification dependency module M
2 waits for module M
1 and both initialize their time slot counter at time 10. M
3 and M
4 initialize at time 9. In view of their processing time the modules will give a next notification at the times complete 2. M
1 is finished at time 20. Because M
2 has waited with initialization for module M
2 it is now finished at time 19. The other two modules are finished at time 18. The slot counter of M
1 is initialized at time 20. The slot counter of M
2, which waits for M
1, is also initialized at time 20. Although M
3 has given its own notification at time 18 it initializes its time slot counter only at time 19 when it has also received the notification from M
2. M
4 is completed at time 18 and has received notification from M
3 at the same time. Hence, M
4 initializes its time slot counter at time 18. At the row complete 3 it is indicated at which times the modules have reached the second operational state for the third time. It can now be seen that module M
4 will not immediately reset its time slot counter, but will wait one time unit as it still has to receive the notification from module M
3. In this way the data-traffic between each of the modules is synchronized, so that buffer over/underflow is prevented.