re-entrant code

Hello,

You are making it too hard! Reentrant functions are not black magic :)

All I'm trying to say is that the design of a reentrant function requires extra attention, i.e. extra time and money, because reentrancy problems are usually very hard to troubleshoot, so it's best to get it right the first time. Hence my feeble attempt to draw a checklist to test for reentrancy (using elbow grease, since there is no software to do that for me).

Agreed that there is no black magic wizardry involved there. I couldn't find any entry on reentrancy in my book of shadows. That said, it's a rather old edition...

Hello,

You are making it too hard! Reentrant functions are not black magic :)

All I'm trying to say is that the design of a reentrant function requires extra attention, i.e. extra time and money, because reentrancy problems are usually very hard to troubleshoot, so it's best to get it right the first time. Hence my feeble attempt to draw a checklist to test for reentrancy (using elbow grease, since there is no software to do that for me).

Agreed that there is no black magic wizardry involved there. I couldn't find any entry on reentrancy in my book of shadows. That said, it's a rather old edition...

But the question here is: why do you need reentrancy?

If you write a thread-safe c library, where the functions should be called from multiple threads, then you need it. And you also need it if you want to call the same function from both an interrupt service routine and a main application.

You need a little bit simpler form of reentrant-safe if the function is part of a recursive chain - in that case you don't have to worry about atomicity of instructions.

The C51 architecture isn't the worlds most powerful, so a lot of applications are implemented without an RTOS. Just a super-loop and a number of ISR. An ISR should be as fast as possible, so normally don't call any functions.

In the end, there isn't too much need for reentrant functions on the C51 architecture.

Hello Per,

Sometimes, reentrancy is needed. Sometimes, it is not. Sometimes, as in the case of the C51 MCU, it makes sense, from an architectural point of view, to ban anything that uses reentrancy, I agree with all that.

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.

Reentrancy cannot be tested. Wicca does not work either. So I will have to be careful about what I write.

This begs the question: is there a finite checklist that I can check my code against, to ensure it is reentrant (thread-safe)?

Steph-

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