re-entrant code

what is a re-entrant code?

Code (for example a function) that can be called safely while the same function is already being run by another task/program/function.

Reentrancy is needed, for example, for recursive function calls, or for functions that are called from multiple tasks without any kind of mutex mechanism.

what is a re-entrant code?

Code (for example a function) that can be called safely while the same function is already being run by another task/program/function.

Reentrancy is needed, for example, for recursive function calls, or for functions that are called from multiple tasks without any kind of mutex mechanism.

Now here is another question: how do you test for reentrancy of such code?

You don't test for reentrancy. You specifically develop with that in mind. Reentrancy is a factor of what resources the function makes use of, and how it uses them.

An example is that if a function needs to change two global variables (and these variables must always be in sync, then the change must be atomic. An example is allocating/releasing memory.

Another example is that a function that reads a global resource may have to protect the read access, to make sure that two instances of the same function reads the same value and then does an updated based on the same value. For example a function that reads a counter, performs some work based on the counter and then increment the counter. If two instances of the same function checks that there are data available in a read queue, they may both process the same character and insert two results based on the same input.

Note that a reentrant function may only call other reentrant functions.

Another example is that a function that reads a global resource may have to protect ........

Pers post abbreviated: stay away from reentrancy.

Erik

stay away from reentrancy.

To be more precise - on a '51, stay away from situations where you may need reentrant functions (e.g. recursive functions, multithreading, calling the same function in ISRs and the regular program, etc)

Erik is a bit rough, but when specifically talking about a C51 processor (it doesn't have a real generic stack), reentrancy costs a lot.

For a C51, most parameters and function-local variables are converted to global variables by the compiler and linker. A reentrant function can not have it's parameters or local variables converted to global variables since each active instance of the function must have a separate set of variables. That's the rule I mentioned in my earlier post about reentrant functions often needing syncronized read and/or write access to global resources.

In short, making a function reentrant on a C51 processor costs memory, code size and speed. Few functions really need to be reentrant. It is better to create several copies of the same function. One copy to call from the main loop, and one copy to call from an interrupt handler. Especially if the interrupt handler are already using a different register bank.

when specifically talking about a C51 processor

I am posting based on that. I see no reason to mention that this is specifically about the C51 when the architecture window states C51.

Erik

It doesn't matter if a thread is about a specific architecture. If the answer sounds general, the OP may assume that the answer really is valid for other architectures too.

Per wrote:

You don't test for reentrancy. You specifically develop with that in mind. Reentrancy is a factor of what resources the function makes use of, and how it uses them.

That's unfortunately what I'm thinking too; and that's a scary fact. I have the feeling that automatic test code that would test for reentrancy would be more difficult to write than the tested code itself.

Therefore, is it safe to say that, a few high-level ways to prove that code is reentrant are:

- by doing a code review

- by having the code generated automatically by a tool that is proven to produce reentrant code

- ... anything else?

And then, we could say that the code review would check, amongst other things:

- code does not call non-reentrant code

- inspected code must be assembly. When inspecting C, one must mentally process every line and imagine what the assembly code would be in the end.

- keeping in mind that in C, some casts, floating point calculations, etc. will in turn call a function in a library, which itself must have been designed for reentrancy. In C++, add to this the army of operators like new delete etc.

- none of the variables that are changed by the reentrant code, can have a fixed address in RAM. That means no "static" variables in C

- there will inevitably be a few lines of code that simply cannot be made reentrant, in which case additional protection mechanism must be used to make sure that it will not be re-entered. Like disabling interrupts, to the cost of increasing interrupt latency.

- self modifying code is not reentrant

- ... ok: what else?

Steph-

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

You can write reentrant code in C. On some architectures, the compiler will directly generate code that is reentrant (this still requires that the developer takes care of accesses to global/static resources). On some architectures, you have to specifically tell the compiler to generate reentrant code. A C51 compiler normally produces non-reentrant code, specifically because of limitations of the C51 architecture.

You can have a reentrant function read and write to global resources. It is just a question of making sure that the function always gives predictable results even if having two concurrent calls active. For axample: A pseudo-random number generator must have code to atomically read its old seed and update it with a new value, to make sure that two concurrent calls doesn't result in the same random number. malloc()/free() or new/delete must protect internal lists of used/released memory.

The compiler vendor documentation will tell if floating-point code, and memory allocation functions etc are reentrant or not.

But as already noted: C51 is not an architecture that likes reentrant functions! You really want the compiler to convert parameters and local variables to reusable global variables because of size and efficiency!

You have to realize that when talking about global variables, the problem is more about architecture than the used code-generating tool.

Most architectures can read an 8-bit variable atomically. But can they read a 16-bit, 32-bit or 64-bit variable atomically?

Some architectures can increment a memory variable atomically, while other architectures may need a load + increment + store. If the variable is too large to increment directly, then the code-generating tool (any tool - or yourself, using assembler) will have to care about overflow rippling to the upper parts of the variable - for example by adding extra add-with-carry steps.

To make Per happy:
This relates to the '51
Since the OP started the thread with C51 I have changed MCU back to the C51 to stay with the OPs intent.

I have never used reentrant code. Yes, I have had cases where it might have been desirable (e.g. a function shared by an ISR and main) but the potential debugging nightmare has kept me from using reentrant code.

I think the OPs worry that he 'might' have reentranr code is greatly overblown. Just make sure that all functions called from ISRs (if you absolutely have to have them) have names that are e.g. ISR..... and no ISR.... function is called from main.

Erik

PS the one '51 case I can see for reentrant code would be to 'core use squeeze' a unit that was to be made in millions.

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-