Rule #2 tells us a calling function inherits the reentrancy problems of the callee. That makes sense, if other code inside the function trashes shared variables; the system is going to crash.

Using a compiled language, though, there's an insidious problem. Are you sure—really sure—that the runtime package is reentrant? Obviously string operations and a lot of other complicated things use runtime calls to do the real work. An awful lot of compilers also generate runtime calls to do, for instance, long math, or even integer multiplications and divisions.

If a function must be reentrant, talk to the compiler vendor to ensure that the entire runtime package is pure. If you buy software packages (like a protocol stack) that may be called from several places, take similar precautions to ensure the purchased routines are also reentrant.

Rule #3 is a uniquely embedded caveat. Hardware looks a lot like a variable, if it takes more than a single I/O operation to handle a device, reentrancy problems can develop.

Consider Zilog's SCC serial controller. Accessing any of the device's internal registers requires two steps: first write the register's address to a port, then read or write the register from the same port, the same I/O address. If an interrupt comes between setting the port and accessing the register another function might take over and access the device. When control returns to the first function the register address you set will be incorrect.

Keeping Code Reentrant
What are our best options for eliminating nonreentrant code? The first rule of thumb is to avoid shared variables. Globals are the source of no end of debugging woes and failed code. Use automatic variables or dynamically allocated memory.

Yet globals are also the fastest way to pass data around. It's not entirely possible to eliminate them from real time systems. Therefore, when using a shared resource (variable or hardware) we must take a different sort of action.

The most common approach is to disable interrupts during nonreentrant code. With interrupts off the system suddenly becomes a single-process environment. There will be no context switches. Disable interrupts, do the nonreentrant work, and then turn interrupts back on.

Most times this sort of code looks like:

long i;
void do_something(void){
    disable_interrupts();
    i+=0x1234;
    enable_interrupts();
}

This solution does not work. If do_something() is a generic routine, perhaps called from many places, and is invoked with interrupts disabled, it returns after turning them back on. The machine's context is changed, probably in a very dangerous manner.

Don't use the old excuse "yeah, but I wrote the code and I'm careful. I'll call the routine only when I know that interrupts will be on." A future programmer probably does not know about this restriction, and may see do_something() as just the ticket needed to solve some other problem . . . perhaps when interrupts are off.

Better code looks like:

long i;
void do_something(void){
    push interrupt state;
    disable_interrupts();
    i+=0x1234;
    pop interrupt state;
}

Shutting interrupts down does increase system latency, reducing its ability to respond to external events in a timely manner. A kinder, gentler approach is to use a semaphore to indicate when a resource is busy. Semaphores are simple on-off state indicators whose processing is inherently atomic, often used as "in-use" flags to have routines idle when a shared resource is not available.

Nearly every commercial real time operating system includes semaphores; if this is your way of achieving reentrant code, by all means use an RTOS. Don't have an RTOS? Sometimes I see code that assigns an in-use flag to protect a shared resource, like this:

while (in_use);          //wait till resource free
in_use=TRUE;         //set resource busy
Do non-reentrant     stuff
in_use=FALSE;       //set resource available

If some other routine has access to the resource it sets in_use true, causing this routine to idle until in_use gets released. Seems elegant and simple, but it does not work. An interrupt that occurs after the while statement will preempt execution. This routine feels it now has exclusive access to the resource, yet hasn't had a chance to set in_use true.

Some other routine can now get access to the resource. Some processors have a test-and-set instruction, which acts like the in-use flag, but that is interrupt-safe. It'll always work. The instruction looks something like:

Tset variable  ;  if  (variable==0){
                        ;       variable=1;
                        ;       returns TRUE;}
                        ;  else {returns FALSE;}

If you're not so lucky to have a test-and-set, try the following:

loop:      mov     al,0             ; 0 means "in use"
              xchg    al,variable
             cmp      al,0
             je          loop             ; loop if in use

If al = 0, we swapped 0 with zero; nothing changed, but the code loops since someone else is using the resource. If al = 1, we put a 0 into the "in use" variable, marking the resource as busy. We fall out of the loop, now having control of the resource. It'll work every time.

Recursion
No discussion of reentrancy is complete without mentioning recursion, if only because there's so much confusion between the two. A function is recursive if it calls itself. That's a classic way to remove iteration from many sorts of algorithms.

Given enough stack space this is a perfectly valid, though tough to debug, way to write code. Since a recursive function calls itself, clearly it must be reentrant to avoid trashing its variables. So all recursive functions must be reentrant, but not all reentrant functions are recursive.

Next in Part 2: Asynchronous hardware/firmware.