re-entrant code

Now: let's say I need to use reentrancy. There are several flavors of it: ISR-safe, thread-safe, recursion-safe, let's say I need something that is thread-safe. Say I'm using RTX51.
While the '51, since it is programmable, is capable of operating with a RTOS the jumping through hoops the '51 architecture requires makes the '51 (with the exception of some PIGs, I guess) the worst possible choice for an application that requires a RTOS. When you then add reentrancy which, again, does not fit the '51 architecture you get problms piled on top of problems.

This begs the question: is there a finite checklist that I can check my code against, to ensure it is reentrant (thread-safe)?
yes, 1) check that no RTOS is involved and 2) do not call functions from ISRs.

you can, since the '51 is programmable, of course use both a RTOS and reentrant functions, but with all the concern you seems to have about "ensuring" I would strongly advise aganst it.

Erik

Now: let's say I need to use reentrancy. There are several flavors of it: ISR-safe, thread-safe, recursion-safe, let's say I need something that is thread-safe. Say I'm using RTX51.
While the '51, since it is programmable, is capable of operating with a RTOS the jumping through hoops the '51 architecture requires makes the '51 (with the exception of some PIGs, I guess) the worst possible choice for an application that requires a RTOS. When you then add reentrancy which, again, does not fit the '51 architecture you get problms piled on top of problems.

This begs the question: is there a finite checklist that I can check my code against, to ensure it is reentrant (thread-safe)?
yes, 1) check that no RTOS is involved and 2) do not call functions from ISRs.

you can, since the '51 is programmable, of course use both a RTOS and reentrant functions, but with all the concern you seems to have about "ensuring" I would strongly advise aganst it.

Erik