Buffer underrun and overrun

Buffer underrun and overrun

The terms overrun and underrun have been described throughout this chapter and have been portrayed as things to be avoided when designing buffers and the system that supports them. While this is generally true, it is not always the case and there are times where they do not constitute an error but indicate some other problem or state in the system.

When a buffer underruns, it indicates that there is no more data in the buffer and that further processing should be stopped. This may indicate an error if the system is designed so that it would never run out of data. If it can happen in normal operation then the data underrun signal indicates a state and not an error. In both cases, a signal is needed to recognise this point. This can be done by comparing the buffer pointer to the buffer memory range. If the pointer value is outside of this range, it indicates that an underrun or overrun has occurred and this can redirect flow to the appropri-ate routine to decide what to do. Valid underrun conditions can occur when incoming data is buffered and not continuously supplied. A break in transmission or the completion of sending a data packet are two common examples. If this break is expected, then the receiving software can complete and go dormant. If the break is due to some other problem, then the receiving software may need to adopt a waiting action to see if other data comes into the buffer and the data reception continues. To prevent the system freezing up and not responding, the waiting action needs to be carefully designed so that there is some kind of timeout to prevent the waiting becoming permanent and locking up the system. This is often the cause of a hung up system that appears to have crashed. What in fact has happened is that it is waiting for data or an event that will not happen.

Data overrun is more than likely caused by some kind of error that results in data being lost because it cannot be accepted. Again in some systems this may not be an error and the system can be designed to carry on. Again pointer comparison can be used to determine when an overrun has occurred. In some cases this may trigger a request to allocate more memory to the buffer so that the incoming data can be accommodated. It may simply result in the data being discarded. Either way, the control software that sur-rounds the buffer can quickly become quite complicated depend-ing on what desired outcome and behaviour is required. In other words, while buffers are simple to construct and use, designing the control software for buffers that are tolerant and can cope with underrun and overrun conditions is more complex. If this is not done then it can lead to many different problems.

If the pointers that are used to define and create buffers are used with no range checking i.e. they are always used on the assumption that the values are within the buffer range and are correct, then there is always the risk that an error condition may cause the pointers to go out of range. If a buffer underruns and the buffer pointer now points to the next memory location outside of the buffer and no checking is done, incorrect data will be supplied and the pointer incremented to the next location. If these locations are also data structures then no real problem will occur providing the locations are read and not written to. As soon as new data arrives for the buffer, it will be stored in the first available location outside the buffer which will overwrite the contents and destroy the data structure. This pointer corruption can quickly start cor-rupting data structures which will eventually reveal themselves as corrupt data and strange system behaviour such as crashes and system hang ups. These types of problems are notoriously difficult to solve as the resulting symptoms may have little to do with the actual cause.

It is recommended that care is taken with buffer design to ensure that both underrun and overrun are handled correctly without causing these type of errors. A little bit of care and attention can reap big dividends when the system is actually tested.