5.6 Table Access Routines

It is not recommended that tables be accessible by all modules as global entities. The developer should try to avoid directly accessing variables in a global table and instead use access routines that encapsulate the data and functions to manipulate the data into specific modules and submodules. Consider the table shown in Figure 5.7. Instead of directly accessing the table with a pointer pTable, it uses the services of a new module called the table management module. This module provides access routines for reading and writing values into this table. External modules will use these access routines only for adding and deleting entries in the table. This concept is quite similar to the encapsulation principles in object-based design.

Figure 5.6: Table access.

The advantage of using access routines becomes apparent in a distributed environment, where both modules run on separate CPUs but access a common table. The access routine implementations will be modified to accommodate this. Other modules using these routines will not see any difference, since the APIs offered by the access routines will not change. Optimizing the access routines for faster access can also be done in isolation, without having to change the modules that need the access.

Application designers should always use standard access routines for their modularity and ease of maintenance.

If the application always uses access routines to manipulate global or local tables, these access routines should also be written such that critical sections are protected with mechanisms like semaphores. This is to ensure that simultaneous invocation of the routines by two different tasks will not cause unpredictable results.

Another benefit of accessing variables with safe access routines is the ability to write reentrant code, a very useful approach in embedded systems. A function is reentrant if it can be invoked by multiple callers at the same time with no side effects on the individual contexts. If variables are changed by the function, the value of the variables needs to be contained within the specific invocation. Reentrant code is useful where multiple contexts of execution are required for the same function(s). Note that a routine is reentrant only if all the routines it calls are reentrant or invocation safe, as in the access routines described here.