Reentrant and asynchronous signal Security
A reentrant function is simply a function that can be interrupted. That is to say, it can be interrupted at any time during function execution and transferred to the OS for scheduling to execute another piece of code, however, no error occurs when the system returns control.
As defined in the multithreaded programming guide, functions that can be safely called by Signal Controllers are called "Asynchronous signal Security" functions.
Therefore, I think reentrant and asynchronous signal security is a concept.Some people confuse reentrant functions with thread-safe functions, which I think is incorrect.
Here we reference the description in csapp to illustrate the following:
--------------------------------------------------
Csapp
13.7.1 thread security
A function is called thread-safe. It always produces correct results when it is repeatedly called by multiple concurrent threads.
13.7.2 reusability
There is an important thread-safe function called reentrant function. It has an attribute that shared data is not referenced when it is called by multiple threads. Although thread security and reentrant are sometimes (incorrect) used as synonyms, there are still clear technical differences between them. The reentrant function is a real subset of thread-safe functions.
-------------------------------------------------- Re-entry means repeated entry. First, it means that this function can be interrupted. Second, it means that it does not depend on any environment (including static) except the variables on its own stack ), such a function is a purecode (pure code) reentrant, which allows multiple copies of the function to run. Since they use a separate stack, they do not interfere with each other.
The reentrant function is a thread-safe function, but in turn, the thread-safe function may not be a reentrant function.
In fact, there are few reentrant functions. apue Section 10.6 describes only 115 reentrant functions described in single UNIX specification; section 12.5 of apue describes functions that cannot guarantee thread security in posix.1, with only 89 functions. Like a hardware interrupt, a signal interrupts the command sequence being executed. The signal processing function cannot determine where the process runs when the signal is captured. If the operations in the signal processing function are the same as those in the interrupted function, and the operation has a static data structure, when the signal processing function returns (of course, the signal processing function can return), restore the original execution sequence, the operations in the signal processing function may overwrite the data in the previous normal operations.
The reason for the non-reentrant function is:
1> they are known to use static data structures
2> they call malloc and free.
Malloc usually maintains a chain table for the allocated storage area, and the process may be modifying the chain table when inserting and executing the signal processing function.
3> they are standard Io functions.
Because many implementations of the standard Io library use the global data structure Even for reentrant functions, you need to pay attention to errno when using the signal processing functions. There is only one errno variable in a thread. The reentrant function used in the signal processing function may also modify errno. For example, the READ function can be reentrant, but it may also modify errno. Therefore, the correct method is to save errno at the beginning of the signal processing function, and restore errno when the signal processing function exits. For example, the program is calling printf output, but when printf is called, a signal is generated, and the corresponding signal processing function also has a printf statement, which will lead to the mixing of the two printf outputs.
If you lock printf, the above situation will lead to a deadlock. In this case, a certain signal is blocked in a specific area.
Method for shielding signals:
1> signal (sigpipe, sig_ign); // ignore some signals
2> sigprocmask ()
Sigprocmask is only defined by a single thread
3> pthread_sigmask ()
Pthread_sigmasks can be used in multiple threads. Now it seems that the asynchronous signal security and reentrant restrictions are the same, so here they are equivalent ;-) Thread Security
Thread safety: If a function can be safely called by multiple threads at the same time, it is called thread safety. When sharing is not required, provide a dedicated data copy for each thread. If sharing is important, explicit synchronization is provided to ensure that the program operates in a definite way. By including the process in the statement to lock and unlock the lock mutex, the whole process of uneasiness can be turned into a thread security process and can be serialized. Many functions are not thread-safe because the data they return is stored in the static memory buffer. By modifying the interface, the caller can independently provide the buffer to make these functions thread-safe.
When the operating system supports thread-safe functions, it will provide some replaceable thread-safe versions for some non-thread-safe functions in posix.1.
For example, gethostbyname () is thread unsafe. in Linux, it provides the thread security implementation of gethostbyname_r.
Add "_ r" after the function name to indicate that this version is reentrant (for threads that can be reentrant, that is, it is thread-safe, but it does not mean that signal processing functions can also be reentrant, or asynchronous signal security ). Common negligence problems in multithreaded programs
1> pass the pointer to the caller stack as a parameter of the new thread.
2> the shared access to global memory can be changed without the protection of synchronization mechanism.
3> two threads attempt to take turns to obtain the same global resource permission, resulting in a deadlock. One thread controls the first resource and the other thread controls the second resource. No thread can continue until one of the threads gives up.
Operation.
4> try to obtain the lock held again (recursive deadlock ).
5> Create a hidden interval in synchronization protection. If the function contained in the protected code segment releases the synchronization mechanism and obtains the synchronization mechanism again before returning the caller, this interval occurs during protection. The results are misleading. On the surface, global data has been protected by the caller, but is not actually protected.
6> when UNIX signals are mixed with threads, The sigwait (2) model is used to process asynchronous signals.
7> call setjmp (3C) and longjmp (3C), and skip for a long time without releasing the mutex lock.
8> the condition cannot be re-evaluated after being returned from * _ cond_wait () or * _ cond_timedwait. Summary
To determine whether a function can be reentrant, it is to determine whether it can be interrupted. After interruption, the function can be restored to run correctly. (The command sequence that interrupts execution does not change the data of the function)
To determine whether a function is thread-safe, it determines whether a function can execute its command sequence in multiple threads at the same time to ensure that each thread can get the correct result. If a function is reentrant to multiple threads, It is thread-safe, but this does not mean that the function can be reentrant to the signal processing program.
If the function is safe for the asynchronous signal processing program, it can be said that the function is "Asynchronous-signal Security. Refer:
Csapp
13.7.1 thread security
13.7.2 reusability
Advanced Programming in the Unix environment 2nd Editon
10.6 reentrant function
12.5 Reentrant
Multi-Thread Programming Guide
Signal Processing Program and asynchronous signal Security
Http://blog.chinaunix.net/u/25994/showart_369466.html |
