Reentrant (reentrancy) vs Thread safety (thread safety)

On the wiki, the re-entry definition is as follows (detailed link)

In computing, a computer program or subroutine are called reentrant if it can be interrupted in the middle of its execution And then safely called again ("re-entered") before their previous invocations complete execution. The interruption could is caused by an internal action such as a jump or call, or by an external action such as a hardware Interrupt or signal. Once The reentered invocation completes, the previous invocations would resume correct execution.

Translate, that is, in the process of executing the function, if an interrupt is forced to perform other actions, when the interrupt execution is completed (the function may be called again during execution of the interrupt), return to the function again, the correct execution process can be resumed.

Clearly, the definition does not emphasize the need to be multi-threaded, and the Wiki further illustrates a fact

This definition originates from single-threaded programming environments where the flow of control could is interrupted by A hardware interrupt and transferred to an interrupt service routine (ISR).

A simple translation, the reentrant definition is based on a single thread, and the control flow can be interrupted by hardware interrupts in the environment. Therefore, the situation of multithreading is not covered and considered in general.

Let's take a look at the thread-safe wiki definition (detailed link)

Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it's manipulates shared data structures in a manner the guarantees safe execution by Multiple threads at the same time. There is various strategies for making THREAD-SAFE data structures.

Simple translation, thread safety is to ensure that the multi-threaded simultaneous execution of functions, the ability to ensure safe execution of the operation of shared data. It is emphasized here that the context of execution must be a multithreaded environment.

From the definition of the above two concepts we can see that Reentrant does not have to be thread safe, and thread safety is not necessarily reentrant.。 Here, you can give two examples to illustrate

First, it is a reentrant, but not thread-safe example. In the following code snippet, the local variable s retains the state of the global variable T and can revert to the original execution state after the break has occurred, conforming to the reentrant definition, but it is clear that it is not thread-safe because it is not possible to ensure global data consistency (no locking)

int t; void swap (int *x, int *y) {    int s;     s = t; Save global variable    t = *x;    *x = *y;     Hardware interrupt might invoke ISR () here!    *y = t;    t = s; Restore global variable} void ISR () {    int x = 1, y = 2;    Swap (&x, &y);}

Then there is a thread-safe, but not reentrant, example. Because the access to the static variable counter is synchronized with the mutex, it is thread-safe. However, if the mutex is acquired, there is an interruption in the process of releasing the lock, and if the function is called again in the interrupt, a deadlock occurs. Therefore is not reentrant.

#include <pthread.h> int increment_counter () {static int counter = 0;static pthread_mutex_t Mutex = pthread_mutex_in Itializer; Pthread_mutex_lock (&mutex); Only allow one thread to increment in a time++counter;//store value before any other threads increment it furtherint r Esult = counter; Pthread_mutex_unlock (&mutex); return result;}

From the above two examples, it is more clear that the relationship between the two does not necessarily depend on one another. In general, the implementation of reentrant to be aware of during function execution, if you want to save the state of execution progress, consider saving the state to a local variable (stack), TLS, cannot be stored in global or static variables, but also note that you cannot call other non-reentrant functions.

Finally, after some search on the web, some people have a different understanding of reentrant. In simple terms, reentrant also includes multithreading, which means that when a single thread is in the process of executing a function, it guarantees the correctness of the execution of the other thread. That is, Reentrant includes the re-entry of a single thread and the re-entry of multiple threads, which is clearly more restrictive and ensures thread safety.

Reentrant (reentrancy) vs Thread safety (thread safety)