Python Learning 41 days (threads)

Today's main content:

Threading Concepts and simple applications

Introduction of threading concept into background process

Before we knew the concept of the process in the operating system, the program could not be run alone, and the program would be allocated resources to run it only if it was loaded into memory, and this kind of execution would be called a process. The difference between a program and a process is that a program is a set of instructions, which is a static descriptive text of the process, and a process is an execution activity of a program, which belongs to the dynamic concept. In multi-channel programming, we allow multiple programs to be loaded into memory at the same time, which can be implemented concurrently under the dispatch of the operating system. This is the design that greatly improves the CPU utilization. The advent of the process makes it possible for each user to feel the CPU alone, so the process is proposed for multi-channel programming on the CPU.

With the process why the thread

The process has many advantages, it provides multi-channel programming, let us feel each of us have their own CPU and other resources, can improve the utilization of the computer. Many people do not understand, since the process is so good, why do threads? In fact, careful observation will find that the process is still a lot of defects, mainly reflected in two points:

• A process can only do one thing at a time, and if you want to do two or more things at once, the process is powerless.

• If a process is blocked during execution, such as waiting for input, the entire process hangs, even if some work in the process does not depend on the input data, it cannot be executed.

If these two shortcomings are difficult to understand, give a realistic example, perhaps you are clear: if we take the course of the process as a process, then we have to do is ear to listen to the teacher lectures, hand also take notes, the brain still have to think about the problem, so as to effectively complete the task of the lectures. And if only to provide the process of this mechanism, the above three things will not be executed at the same time, can only do one thing, listen to the time can not take notes, and can not use the brain to think, this is one; if the teacher wrote the calculation process on the blackboard, we began to take notes, and the teacher suddenly had a step down, blocked He was thinking over there, and we couldn't do anything else, even if you wanted to think about a problem you didn't understand just now, which is second.

Now you should understand the defects of the process, and the solution is very simple, we can let listen, write, think three independent process, parallel together, so it is obvious to improve the efficiency of lectures. The same mechanism, the thread, is also introduced in the actual operating system.

The appearance of the thread in the 60 's, in the OS can have resources and independent operation of the basic unit is the process, but with the development of computer technology, the process has a lot of drawbacks, one is because the process is the resource owner, create, undo and switch There is a large space-time overhead, so need to introduce Light ProcessThe second is due to the presence of symmetric multiprocessor (SMP), can satisfy multiple operating units, and multiple processes are too expensive to parallel. So in the 80 's, there was units capable of running independently--Thread (Threads) . Note: A process is the smallest unit of resource allocation, and a thread is the smallest unit of CPU scheduling. there is at least one thread in each process. Back to Top relationship of processes and threads

　　

the difference between a thread and a processCan be summed up in the following 4 points: 1) address space and other resources (such as open files): Processes are independent of each other and shared among threads of the same process.　　Threads within a process are not visible in other processes.　　2) Communication: Inter-process communication IPC, between threads can directly read and write process data segments (such as global variables) to communicate-the need for process synchronization and mutual exclusion means of support to ensure data consistency.　　3) Scheduling and switching: Thread context switches are much faster than process context switches.　　4) in a multithreaded operating system, the process is not an executable entity. * Learn about thread-to-town through comics
features of the threadIn a multithreaded operating system, it is common to include multiple threads in a process, each as the basic unit of CPU utilization, and an entity that spends the least overhead.　　The thread has the following properties.　　1) entities in a lightweight entity thread do not have system resources at all, just a bit of an essential resource that can guarantee independent operation. The entities of the thread include programs, data, and TCB. A thread is a dynamic concept, and its dynamic nature is described by the thread control block TCB.

The TCB includes the following information: (1) thread state. (2) when the thread is not running, the field resource is saved. (3) A set of execution stacks. (4) store the local variable memory area of each thread. (5) access to main memory and other resources in the same process. A set of registers and stacks that indicate the program counter, the reserved local variable, the few state parameters, and the return address of the instruction sequence being executed. The TCB includes the following information

2) The basic unit of independent Dispatch and dispatch. In multi-threaded OS, threads are the basic units that can run independently, and thus are the basic units of independent Dispatch and dispatch.　　Because the thread is "light", the thread switches very quickly and with little overhead (in the same process). 3) Share process resources.threads in the same process can share the resources owned by the process, which first manifests that all threads have the same process ID, which means that the thread can access every memory resource of the process, and also access the open files, timers, semaphores, etc. owned by the process. Because threads in the same process share memory and files, there is no need to call the kernel to communicate with one another. 4 ) can be executed concurrently. in a process between multiple threads, can be executed concurrently, and even allow all threads in a process to execute concurrently, also, the threads in different processes can execute concurrently, take full advantage of and play the processor and peripheral equipment to work in parallel. Go back to the top of the actual scene using the thread

Open a word processing software process, the process must do more than one thing, such as listening to keyboard input, processing text, automatically save the text to the hard disk, the three tasks are the same piece of data, and therefore can not be used multi-process. Only in one process can open three threads concurrently, if it is a single thread, it can only be, keyboard input, can not handle text and auto-save, automatically save the text can not be entered and processed.

In-Memory threads

Multiple threads share resources in the address space of the same process, which is a simulation of multiple processes on a single computer, sometimes referred to as a lightweight process.

For multiple processes on a single computer, you share physical memory, disks, printers, and other physical resources. Multi-threaded running is similar to running multiple processes, which is a fast switchover between multiple threads by the CPU.

The different processes are full of hostility, each other is preemption, competition CPU relationship, if Thunderbolt will and QQ Rob Resources. And the same process is created by a programmer's program, so the thread within the same process is a partnership, one thread can access the memory address of the other thread, everyone is shared, and one thread dries the memory of another thread, which is purely a problem for the programmer.

Similar to the process, each thread also has its own stack, unlike the process, where the line libraries cannot force the thread out of the CPU using the clock interrupt, and can call the Thread_yield run thread to automatically abandon the CPU and let another thread run.

Threads are usually useful, but the problem with threading is that it is difficult to design a program:

1. If the parent process has multiple threads, does the open child thread require the same number of threads

2. In the same process, if one thread closes the file and another thread is preparing to write to the file?

Therefore, in multithreaded code, more attention is needed to design the program's Logic and protect the program's data.

Back to top user-level threads and kernel-level threads (Learn)

Thread implementations can be divided into two categories: User-level threads (user-level thread) and kernel thread threads (kernel-level thread), which are also known as kernel-supported threads or lightweight processes. In multi-threaded operating system, the implementation of each system is not the same, in some systems to implement the user-level threads, and some systems to implement the kernel-level threads.

User-level threads

Kernel switching by the user state program itself control the kernel switch, do not need the core interference, less in and out of the kernel state consumption, but not very good use of multi-core CPU.

　　

The user space simulates the scheduling of the operating system to invoke a thread in a process, and each process has a runtime system to dispatch the thread. At this point, when the process acquires the CPU, the process then dispatches a thread to execute, and only one thread executes at the same time.

Kernel-level threading

Kernel-level thread: The switch is controlled by the kernel, and when the thread switches, the user state is converted to the kernel state. The switch is completed to return the user state from the kernel state, and the SMP can be used to make use of the multi-core CPU. This is the case with Windows threads.

　　

Kernel support threads are perceived by the OS kernel, while user-level threads are not perceived by the OS kernel. The creation, revocation, and dispatch of user-level threads do not require the support of the OS kernel, which is handled at the level of language (such as Java), while kernel support for thread creation, revocation, and dispatch requires the OS kernel to provide support, and is generally the same as process creation, revocation, and scheduling. When a user-level thread executes a system call instruction, it causes its owning process to be interrupted, while the kernel support thread executes the system call instruction, causing the thread to be interrupted only. In a system that has only a user-level thread, the CPU is dispatched in a process that is in a running state, and the user program controls the rotation of the thread, and in a system with kernel support threads, the CPU is dispatched in threads, and the thread scheduler of the OS is responsible for the thread's dispatch. The program entity of a user-level thread is a program that runs under a user-state, while a kernel-enabled program entity is a program that can run in any state. The difference between a user-level thread and a kernel-level thread

Advantage: When there are multiple processors, multiple threads of a process can execute concurrently. Cons: Dispatched by the kernel

Advantage: The thread scheduling does not require the kernel to participate directly, the control is simple. Can be implemented in an operating system that does not support threading. Thread management, such as creating and destroying threads, thread switching costs, and so on, is much less expensive than kernel threads. Allow each process to customize its own scheduling algorithm, thread management is more flexible. Threads can take advantage of more table space and stack space than kernel-level threads. Only one thread is running in the same process, and if one thread is blocking with a system call, the entire process is suspended. Also, a page failure can cause the same problem. Disadvantage: Resource scheduling according to the process, multiple processors, the same process of the thread can only be in the same processor time-sharing the advantages and disadvantages of user-level threading

Hybrid implementations

User-level and kernel-level multiplexing, kernel same dispatch kernel thread, each kernel thread corresponding to n user thread

　　

NPTL of Linux operating system

  history before kernel 2.6 The scheduler entity is a process, and the kernel does not really support threads. It can be implemented by a system called Clone (), which creates a copy of the calling process, which, unlike fork (), completely shares the address space of the calling process. Linuxthread is used by this system to provide thread support at the kernel level (many of the previous thread implementations are entirely in the user state, and the kernel does not know the existence of the thread at all). Unfortunately, there are quite a few places in this approach that do not follow POSIX standards, especially in the areas of signal processing, scheduling, inter-process communication primitives, and so on. Obviously, in order to improve the linuxthread, the kernel must be supported, and the line libraries needs to be rewritten. To achieve this, there are two competing projects: IBM-initiated NGTP (Next Generation POSIX Threads) project, and Redhat Company's NPTL. In 2003, IBM gave up the NGTP, which is about then, Redhat released the original NPTL. NPTL was first released in Redhat Linux 9 and now supports NPTL from the RHEL3 kernel 2.6 and is fully part of the GNU C library. The design NPTL uses the same approach as Linuxthread, where the thread is still treated as a process and still uses the clone () system call (called in the NPTL Library). However, NPTL requires special support at the kernel level, such as the thread synchronization primitive Futex that needs to hang and then wake the thread. NPTL is also a 1  *1 line libraries, that is, when you use the Pthread_create () call to create a thread, a scheduler entity is created in the kernel accordingly. In Linux it is a new process, and this method is most likely to simplify the implementation of the thread. There is also a m*n model in addition to NPTL's 1  model, which typically has more user threads than the kernel's scheduler entity. In this implementation, the line libraries itself must deal with the possible scheduling, so that the context switch inside the online libraries is usually quite fast because it avoids the system call going to the kernel state. This model, however, increases the complexity of threading implementations and may have problems such as priority reversal, and how user-state scheduling can be reconciled with kernel-state scheduling is difficult to satisfy. Describes the  

Thread and python back to top theoretical knowledge global interpreter lock Gil

The execution of the Python code is controlled by the Python virtual machine (also known as the interpreter main loop). Python was designed to take into account the main loop, while only one thread was executing. Although the Python interpreter can "run" multiple threads, only one thread runs in the interpreter at any time.
Access to the Python virtual machine is controlled by the global Interpreter Lock (GIL), which ensures that only one thread is running at the same time.

In a multithreaded environment, the Python virtual machine executes as follows:

A, set GIL;

b, switch to a thread to run;

C, run a specified number of bytecode instructions or threads actively give up control (can call Time.sleep (0));

D, set the thread to sleep state;

e, unlock GIL;

D. Repeat all of the above steps again.
The Gil will be locked until the function ends (because no Python bytecode is running, so there is no thread switching) when calling external code (such as C + + extension functions), programmers who write extensions can actively unlock the Gil.

Selection of the Python threading module

Python provides several modules for multithreaded programming, including thread, threading, and queue. The thread and threading modules allow programmers to create and manage threads. The thread module provides basic threading and lock support, and threading provides a higher-level, more functional thread-management capability. The queue module allows a user to create a data structure that can be used to share information between multiple threads.
Avoid using the thread module because the higher-level threading modules are more advanced, the support for threading is better, and the use of attributes in the thread module may conflict with the threading, followed by a low level of synchronization primitives for the thread module ( There is actually only one, and the threading module is a lot; Moreover, in the thread module, when the main thread ends, all threads are forced to end, no warnings and no normal cleanup work, at least the threading module ensures that the important child threads exit after the process exits.

The thread module does not support daemon threads, and when the main thread exits, all child threads are forced to quit, regardless of whether they are still working. While the threading module supports the daemon thread, the daemon thread is typically a server waiting for a client request, and if no client requests it, it waits, if a thread is set to be a daemon, it means that the thread is unimportant, and the process exits without waiting for the thread to exit.

Threading Module

The Multiprocess module completely imitates the interface of the threading module, which has a great similarity in the use level, so it is no longer described in detail (official link)

Creation of thread Threading.thread class thread

 fromThreadingImportThreadImport TimedefSayhi (name): Time.sleep (2)Print('%s Say hello'%name)if __name__=='__main__': T=thread (target=sayhi,args= ('Egon',)) T.start ()Print('Main Thread') How to create threads 1

 fromThreadingImportThreadImport TimeclassSayhi (Thread):def __init__(Self,name): Super ().__init__() Self.name=namedefRun (self): Time.sleep (2)        Print('%s Say hello'%self.name)if __name__=='__main__': T= Sayhi ('Egon') T.start ()Print('Main Thread') How to create threads 2

Multi-Threading vs. Multi-process

 fromThreadingImportThread fromMultiprocessingImportProcessImportOSdefWork ():Print('Hello', Os.getpid ())if __name__=='__main__':    #part1: Open multiple threads under the main process, each with the same PID as the main processT1=thread (target=Work ) T2=thread (target=Work ) T1.start () T2.start ()Print('Main thread /master process PID', Os.getpid ())#part2: Open multiple processes with different PID for each processP1=process (target=Work ) P2=process (target=Work ) P1.start () P2.start ()Print('Main thread /master process PID', Os.getpid ()) PID comparison

 fromThreadingImportThread fromMultiprocessingImportProcessImportOSdefWork ():Print('Hello')if __name__=='__main__':    #to open a thread under the main processT=thread (target=Work ) T.start ()Print('Main thread /master process')    " "print Result: Hello main thread/main process" "    #to open a child process under the main processT=process (target=Work ) T.start ()Print('Main thread /master process')    " "Print Result: main thread/main process Hello" "Open the Battle of efficiency

 fromThreadingImportThread fromMultiprocessingImportProcessImportOSdefWork ():GlobalN N=0if __name__=='__main__':    #n=100    #p=process (target=work)    #P.start ()    #P.join ()    #print (' main ', N) #毫无疑问子进程p已经将自己的全局的n改成了0, but only to its own, to view the parent process n is stillN=1T=thread (target=Work ) T.start () T.join ()Print('Master', N)#View the result as 0 because the in-process data is shared among threads in the same processdo threads in the same process share the process's data? Sharing problems with memory data

Python Learning 41 days (threads)