Delays and Timeouts

These are lecture notes from my Computer Science course. For learning about real-time systems, I recommend Real-Time Systems and Programming Languages.

Delaying a process

You could use some hideous delaying loop – a ‘busy-wait’, but that’s not very good. Instead you have delay x.xx or sleep.

There’s a lot going on when you delay; granularity afterwards, interrupts being disabled, and other processes running and your process in the waiting queue. So really delay means ‘delay at least this amount’.

Periodic Activity

To do periodic activity, you shouldn’t just delay x.xx because of how long your activity might take. So for example instead, you do something like:

Next_Time := Clock + 7.0;
loop
	-- do stuff;
	delay until Next_Time;
	Next_Time := Next_Time + Interval;
end loop

This way, it will run on average every 7 seconds, with only local drift making a difference. If the ‘do stuff’ section takes 8 seconds, the delay statement will just have no effect.

Timing Verification

In most embedded systems the timing requirements are very simple, the difficult bit is meeting these requirements in the implementation.

Verification is done in terms of temporal scopes; blocks of code. You have various different ‘things’ that you want as a requirement:

  • Deadline: the time by which the execution of a TS must be finished.
  • Minimum Delay: the minimum amount of time that must elapse before the start of execution of a TS.
  • Maximum execution time: of a TS
  • Maximum elapse time: of a TS.

Temporal scopes tend to be repetitive, therefore you measure the temporal scope in terms of a single repetition. This may just be a ‘periodic’ scope which runs after every x delay. It may also be ‘aperiodic’ e.g. waiting for an interrupt then running, in which case the TS is the ‘running’ bit (not waiting for the interrupt, obviously).

Deadlines can be Hard, Soft, Firm, or Interactive. I lost track of the differences and stuff…

This entry was posted in lecture, rts. Bookmark the permalink.