Reentrancy

Actually, Ive discussed reentrancy already but without naming it. Ive talked about interrupts and preemption, and Ive talked about what semaphores do to help you make a piece of code atomic. Interrupts and multi-threaded programming environments are wonderful things, but they add complexity to your code because they create the possibility that a function can be executing simultaneously in more than one context. The error in the LED example (Listing B.1 where one functions results are lost, causing the wrong LEDs to be lit) happens because the function was not designed to handle the possibility of reentrancy. A function is considered re-entrant only if it can safely be called simultaneously from multiple threads or processes. In this case (Listing B.1), the solution was to eliminate the possibility of reentrancy by using the semaphore. In other cases, the code may be prepared to allow reentrancy.

Use of globals or statics in functions can also cause a function to be non-re-entrant. Similar to the LED state, if a function is in the process of modifying a global variable but is interrupted in the middle of the modification by some other task that tries to manipulate the same data, the data is likely to be corrupted. Generally re-entrant functions use all local (stack) variables whenever possible. ( Variables on the stack are always private to the thread that created them.) When a function needs to manipulate a global resource and still needs to be re-entrant, it should use some form of mutual exclusion to serialize access to the global resource.