Easy re-entry and thread-safe introduction

Reentrant and thread safe

The two terms, reentrant and thread safe, are frequently used in computer programming to indicate the use of classes and functions in multithreaded programs.

Reentrant: If a program or subroutine can be "safely executed in parallel (Parallel computing)", it is referred to as reentrant (Reentrant or re-entrant).

If a function is reentrant, the function:

1, can not contain static (global) very data.

2. You cannot return the address of a static (global), very data.

3. Only data provided by the caller can be processed.

4, can not rely on the single-instance mode resource lock.

5. Cannot invoke (call) non-reentrant functions.

Thread safety: When a function or library is called in a multithreaded environment, it can correctly handle the local variables of each thread and make the program function complete correctly.

Thread-safe methods can be called concurrently by multiple threads, even if they use shared data because the use of shared data is serialized, which means that each sequence operation cannot be interrupted by the use of another thread until it is fully completed. Reentrant methods can also be called by multiple threads at the same time, but each call must use only its own data. Therefore, thread-safe methods must be reentrant, but reentrant methods may not be thread-safe.

A class is reentrant, meaning that each thread uses an instance of a different class. A class is thread-safe, meaning that its member methods can be safely invoked by multiple threads at the same time, even if each thread is using the same class instance.

C + + classes are generally reentrant, because the member methods of a class typically only manipulate member data, each of which invokes a member method through its own class instance, and there is no way that other threads can invoke the same class instance.

The following class is not reentrant, and it is obvious that there are static data members.

Class Counter

{

Public

Counter () {}

static void Increment () {++n;}

static void Decrement () {--n;}

static int value () {return n;}

Private

static int n;

};

Class Counter

{

Public

Counter () {}

void Increment () {++n;}

void Decrement () {--n;}

int value () {return n;}

Private

int n;

};

Simply change it and remove the static to become a reentrant class. But it is not thread-safe, and when there are multiple threads trying to modify N, the result is probably undefined. Because the + + and-operations are not atomic operations, they include the following steps:

1. Load the variable into a register.

2, register for self-increment or self-reduction.

3. Re-save the value of the register to the variable.

Suppose there are two threads A and b that hold the old values of n into the registers, then each self-increment, and then write back to the variable, so that the overwrite occurs, and n actually increases by only 1. As mentioned above, the thread-safe approach to data must be a sequence of non-interruptible, as in the above example, thread A in the implementation of the steps of the X-ary must be continuous operation, before the completion of 3 steps, thread B does not allow the operation of N. Therefore, we generally have to use mutual exclusion variables to lock data operations. As follows

Class Counter

{

Public

Counter () {n = 0;}

void Increment () {Qmutexlocker locker (&mutex); ++n;}

void Decrement () {Qmutexlocker locker (&mutex);--n;}

int value () const {Qmutexlocker locker (&mutex); return n;}

Private

mutable Qmutex int n;

};

Qmutexlocker to n plus lock and unlock to ensure that the operation of N is serialized. We know that the const member method cannot alter any data for the instance, so the mutex must be declared as mutable, because the mutex is changed by locking and unlocking at value () Const.

Many of the classes in QT are reentrant, but not as thread-safe, because it is cumbersome to ensure that thread security is duplicated and unlocked in each method.

The two concepts of reentrant and thread safety are related to how the function handles resources. The reentrant concept affects the external interface of the function, and thread safety concerns only the implementation of the function.

In most cases, to change a non-reentrant function to reentrant, you need to modify the function interface so that all data is provided by the caller of the function.

To change a non-thread-safe function to thread-safe, you only need to modify the implementation portion of the function. In general, the synchronization mechanism is added to protect shared resources from being accessed by several threads at the same time.

http://blog.csdn.net/hai200501019/article/details/8496989

Easy re-entry and thread-safe introduction