Introduction to Reentrant functions and non-reentrant functions in Linux

reentrant functions

Reentrant functions (that is, functions that can be interrupted) can be invoked by more than one task without worrying about data destruction. Reentrant functions can be interrupted at any time, and after a period of time can resume operation, and the corresponding data will not be destroyed or lost.

There are two scenarios for variables that can be used by reentrant functions:

1. Using local variables, the variables are stored in the CPU registers or on the stack;

2. Use global variables, but pay attention to protecting global variables at this time (prevent tasks from being interrupted by other tasks).

void strcpy (*DEST,*SRC)
{while
    (* dest++ = *src + +) {;}
    *dest = NUL;
｝

Analysis: The above function is used for string copying, and parameters are stored on the stack, so the modification function can be invoked by multiple tasks without fear of destroying each other's pointers during each task invocation.

Basically, the following functions are not reentrant:

1. Static data is used within the function.

2. The malloc () or free () function is used within the function.

3. The standard I/O functions are called within the function.

int temp;
 void swap (int *ex1,int *ex2)
{
    temp = *ex1;//(1)
    *ex1 = *ex2;
    *ex2 = temp;
｝

Analysis: The global variable in this function, the temp function, becomes a function that cannot be reentrant. Because in a multitasking system, if you call the Swap function in Task 1 and the program executes to (1), it is interrupted to perform the other Task 2, and just the task 2 also calls the SWAP function. The value stored in temp will be changed by Task 2. Thus returning to the task 1 interrupted, the value stored in temp is no longer the original temp value, resulting in an error. Common methods for reentrant functions are: 1. Do not use global variables to prevent other code from overwriting the values of these variables. 2. Turn off the interrupt before calling this type of function, and then open the interrupt immediately after the call. Prevents interrupts from being interrupted during function execution into other tasks. 3. Use semaphores (mutually exclusive conditions). In short: to ensure that the interruption is safe

Non-reentrant function

Under the multitasking system, interrupts may occur at any time of the task's execution, and if a function is interrupted during execution, and the environment on which the function depends does not change, the function is reentrant, otherwise it cannot be reentrant.

Do you want to save and restore the context before and after the interruption, how can the environment on which the function depends change?

We know that we do save some context when we interrupt, but only a few contexts such as the return address, CPU registers, and so on, and the functions used inside such as global or static variables, buffer, etc. are not protected, so if these values change during the interruption of the function, Then when the function goes back to the breakpoint, the result is unpredictable.

Most of the following conditions are not reentrant:

(1) The use of static data structure;

(2) The malloc or free is invoked;

(3) The standard I/O function is called;

(4) A floating-point operation is performed.

Malloc/free are not reentrant, they use global variables to point to the free zone; many implementations of standard I/O libraries use global data structures; In many processors/compilers, floating point is generally not reentrant (floating-point operations are mostly implemented using coprocessor or software simulations).

Special attention should be paid to signal processing programs and multithreaded programming.

Consider this situation:

1 Signal processing program a both inside and outside of the call of the same non-reentrant function b;b during the execution by the signal interrupted, into a (a) called B, after the end of the return B was interrupted to continue execution, when the B function environment may change, the results of unpredictable.

2 multi-threaded sharing of resources within the process, if two threads a,b call the same non-reentrant function f,a thread into the F, thread scheduling, switching to b,b also executed F, then when switching to thread A, the result of its call F is also unpredictable.

There are problems to be noted in a signal handler even if a reentrant function is invoked. As a general rule, when you call a weight in a signal handler

When you enter a function, you should save the errno before it, and then restore errno. (To understand that the signal that is often caught is SIGCHLD, its signal handler usually calls a wait function, and various wait functions can change the errno.) )