reentrant Functions and thread safety

Introduction:

A set of concurrent threads runs in the same process context, with each thread having its own separate thread context, including thread ID, stack, stack pointer, program counter, condition code, and general purpose register. Each thread shares other parts of the process context with other threads, including the entire user virtual address space (consisting of code snippets, read/write data, heaps, and all the code and data areas of the shared library). Threads also share open collections of files. When a shared resource exists, access to the resource needs to be synchronized. This is the time to write a program using a thread, and you need to write a function with thread-safe properties. A function that can be called thread-safe if and only if it is called repeatedly by multiple concurrent threads, can be referred to as threading security, otherwise we call it non-thread safe.

Features to re-enter:

1. Since reentrant functions can be called multiple times without error, there is no need to worry about data corruption;

2. reentrant function can be interrupted at any time, after a period of time can be run, the corresponding data will not be lost;

3. reentrant functions use only local variables, which are stored in the CPU registers or stacks, and are protected with global variables;

Non-reentrant features:

1. Using the Malloc/free function, the malloc function manages the stack with a global list;

2. Calling standard I/O library functions, many implementations of standard I/O libraries use global data structures in a non-reentrant manner;

3. Can re-enter the body using a static data structure;

Common non-reentrant functions are:

The printf----References global variables stdout

malloc---Global memory allocation table

Free------global memory allocation table

Thread Safety and Reentrant:

A reentrant definition is derived from a single-threaded environment. In a single-threaded environment, a piece of code may be interrupted by hardware during execution and instead invoke an Interrupt service program (ISR). Before this call to interrupt handler function, it is possible that the interrupt handler function is already executing. Therefore, any interrupt handler function should be reentrant.

The concept of thread safety is derived from a multithreaded environment. The origins are not the same, then there is no inevitable relationship between them.

Interview questions:

Interrupts are an important part of embedded systems. The New keyword _interrupt. The following code uses the _interrupt keyword to define an interrupt service subroutine (ISR), and then comments the following code;

__interrupt Double Compute_area (double radius) {Double area = PI * radius * RADIUS;    printf ("\narea =%f", area); return area;}

Code Error:

1. The ISR cannot return a value.

2. The ISR cannot pass parameters.

3, in many processors/compilers, floating point is generally non-reentrant. Some processors/compilers need to put extra registers into the stack, and some processors/compilers you just don't allow floating-point operations in the ISR. In addition, the ISR should be short and efficient, and it is unwise to do floating-point operations in the ISR.

4, printf () often have re-entry and performance problems.

Then there should be a principle here:

1, do not use static variables and global variables, persist only with local variables

2. If you must use global variables, use mutually exclusive semaphores to protect global variables

3, get to know which system calls are reentrant, and use secure system calls in multi-tasking handlers

4. Do not call any other non-reentrant functions

5. Use Malloc/free carefully

reentrant Functions and thread safety