I was going through a re-entrancy guide on recommended practices when writing re-entrant code.
What other references and resources cover this topic?
What lint-like tools can be used to check for these issues?
The guide is sufficient.
My personal rule of thumbs are only 2 for re-reentering code:
take only pass by value parameters, used only value passed in as parameters in the function.
if I need to use any global parameters or pointer (for performance or storage sake), use a mutex or semaphore to control access to it.
- Do use local variables.
- Don't use static locals or global variables, even TLS will not help you with recursion / reentrancy.
- Restore all your invariants before doing callbacks.
- Don't hold locks while you do callbacks. If you absolutely must (and I would still go looking for a way to avoid it) then make sure you know what happens if you try to re-enter your lock on the thread that already holds it. At a minimum you have to test for this, otherwise depending on the lock you'll get deadlocks or broken invariants (i.e. corruption).
None really. Writting non-reentering code is usually more difficult than re-entring. Just follow those simple guidelines and don't try to do anything too waky and you'll be fine.
Non-reentering code is usually written for high-performance issues.
- A reentrant function may not use variables in a non-atomic way unless they are stored on the stack of the calling task or are the private variables of that task.
- A reentrant function may not call other functions which are not reentrant.
- A reentrant function may not use the hardware in a non-atomic way.
Ref: Page 462 [AN INTRODUCTION USING THE RENESAS RX62N MICROCONTROLLER] [James M. Conrad]
来源：https://stackoverflow.com/questions/3240241/recommended-practices-for-re-entrant-code-in-c-c