Re-entrant Code

• Reentrant code can be interrupted anywhere while running on one task and reentered by another task without corrupting data or the state that was interrupt. It should then be able to resume without problems.
• Problem areas
  • Globals
  • Outside data
  • Needing consistency in a data structure
• Design considerations
  • Using the stack for data
  • Allocating memory on a per*task basis
  • The caller allocates memory for the data and passes it to the reentrant function.
    • Allocates either from the stack or heap.
  • Stack memory
    • Valid only for the life time of the function that allocates it.
    • The compiler will try to keep the variable in registers and not use the stack if it doesn’t have to. But if the function takes the address of a variable, then the compiler will the stack.
    • Ok to pass pointers to child functions.
    • Bad to pass it back to parent function
      • Can lead to hard to find bugs since the memory may work a lot of the time but only fail occansionally.
      • Data will remain until the call stack grows enough to over write the data.
  • Critical Sections
    • Disable interrupts for a block of code.
    • Big hammer since it affects the entire system. Interrupts are off for all tasks.
    • Prevents all contexts switches.
    • Should be used sparingly.
    • Important use is in the kernel since it has to maintain state across all tasks.
  • Semaphores
    • Enable localized protection of resources.
    • Reentrant code can use it to protect blocks of data since the semaphores are held be the tasks and not the function.
    • The lock is pre task.
    • The number of semaphores can be made to match the number of resources one is protecting.
  • Mutexes
    • A mutex may be a better choice for reentrant code that will be shared by different priority tasks.
    • Helps avoid priority inversion that might occur if the low priority task gets preempt in the middle of protected section and thus blocks the higher priority task waiting to run.