Thread control and fork

When the thread calls fork, it creates a copy of the whole process address space for the child process. Recall interval.

By inheriting copies of the entire address space, the child process also inherits the status of all mutex, read/write locks, and condition variables from the parent process..If the parent process contains multiple threads and the child process does not call exec immediately after the fork returns, the lock state needs to be cleared.

There is only one thread in the child process. It is composed of copies of the thread that calls fork in the parent process.. If the thread in the parent process occupies the lock, the child process also occupies the lock. The problem is that the sub-process does not contain copies of the thread that occupies the lock. Therefore, the sub-process cannot know which locks it occupies and which locks need to be released.

This problem can be avoided if a sub-process calls an exec function immediately after the fork returns. In this case, the old address space is discarded, so the lock status does not matter. However, if the sub-process needs to continue to do the processing work, this method will not work and other policies need to be used.

To clear the lock status, you can call the pthread_atfork function to create a fork processing program.

#include <pthread.h> pthread_atfork( (*prepare)(),  (*parent)(),  (*child)(

You can use the pthread_atfork function to install up to three functions to help clear the lock.Prepare The fork handler is called by the parent process before the fork creates a child process. The task of this fork handler is to obtain all the locks defined by the parent process.Parent The fork processing program is called in the parent process environment after the fork creates a child process, but before the fork returns, the fork processing program's task isPrepareAll the locks obtained by the fork Handler are unlocked.ChildThe fork handler is called in the sub-process environment before the fork returns.ParentLike fork processors,ChildThe fork handler must also be released.PrepareAll the locks obtained by the fork handler.

Note that the lock will not be unlocked twice at a time, although it may appear. When the child process address space is created, it obtains copies of all the locks defined by the parent process. BecausePrepareThe fork handler obtains all the locks. The memory in the parent process and the memory content in the child process are the same at the beginning. When the Parent and Child processes unlock copies of their locks, the new memory is allocated to the child process, the memory content of the parent process is copied to the memory of the child process (write-time replication), so it will fall into the illusion that the parent process locks all its copies, the child process locks all its copies. The parent process and child process unlock the duplicate locks at different memory locations, as if the following time series appeared:

(1) The parent process acquires all locks.

(2) The sub-process obtains all the locks.

(3) The parent process releases its lock.

(4) The sub-process releases its lock.

You can call the pthread_atfork Function Multiple times to set multiple fork handlers. If you do not need to use a specific handler, you can pass in a null pointer to a specific handler parameter so that they do not play any role. When multiple fork handlers are used, the calling sequence of the handlers is different.ParentAndChildFork handlers are called in the order they are registered, whilePrepareThe order in which fork handlers are called is the opposite of the order in which they are registered. This allows multiple modules to register their own fork handlers and maintain the lock layer.

For example, assume that module A calls the functions in Module B and each module has its own lock. If the lock level is A before B, Module B must set the fork processing program before module. When the parent process calls fork, it performs the following steps, assuming that the child process runs before the parent process.

(1) Call the prepare fork handler of module A to obtain all locks of module.

(2) Call the prepare fork handler of Module B to obtain all locks of Module B.

(3) create a sub-process.

(4) Call the child fork handler in Module B to release all the locks of Module B in the child process.

(5) Call the child fork handler in module A to release all the locks of module A in the child process.

(6) The fork function returns to the child process.

(7) Call the parent fork handler in Module B to release all the locks of Module B in the parent process.

(8) Call the parent fork handler in module A to release all the locks of module A in the parent process.

(9) The fork function returns to the parent process.

If the fork handler is used to clear the Lock State, who is responsible for clearing the state of the condition variable? In some operating systems, conditional variables may not need to be cleaned up. However, some operating systems use locks as part of the conditional variable implementation. In this case, the conditional variables need to be cleared. The problem is that such an interface does not exist currently. If the lock is embedded in the data structure of the condition variable, conditional variables cannot be used after fork is called, because there is no portable method to clean up its status. In addition, if the operating system uses a global lock to protect all the conditional variable data structures in the process, the operating system itself can clear the lock in the fork library routine, however, applications should not rely on such details in the operating system implementation.

Instance

The program in listing 12-7 describes how to use the pthread_atfork and fork handlers.

Program list 12-7 pthread_atfork instance

#include <pthread.h>==&&&&&& * *( defined(BSD) || defined(MACOS)    ((err = pthread_atfork(prepare, parent, child)) != = pthread_create(&tid, NULL, thr_fn, (err != ((pid = fork()) <  (pid == )        

The program defines two mutex values: lock1 and lock2. The prepare fork handler obtains the two locks. The child fork handler releases the lock in the sub-process environment, the parent fork handler releases the lock in the parent process.

Run the program and get the following output:

We can see that the prepare fork processing program runs after fork is called, and the child fork processing program runs before the fork call returns to the sub-process, the parent fork handler runs before the fork call is returned to the parent process.

This blog is excerpted from advanced programming for UNIX environments (version 2) and used only for personal learning records. For more information about this book, see:Http://www.apuebook.com/.