Gil Global interpreter lock and process pool. Thread pool

Gil Global Interpreter Lock

Gil is essentially a mutex, which is clamped on the interpreter, and all threads within the same process need to grab the Gil lock before executing the interpreter code

The advantages and disadvantages of Gil:

Pros: Ensure thread safety for CPython interpreter memory management

Disadvantage: All threads in the same process can only have one execution at the same time, that is, the multithreading of the CPython interpreter cannot be parallelized and the multi-core advantage cannot be achieved

Gil with single thread

There is a Python interpreter code in the memory space of each process, so the Gil lock is not thread-scrambling in the case of a single thread, and only the garbage collection mechanism thread gets the Gil permissions periodically.

Gil and multithreading

With the Gil present, only one thread can execute at the same time within each process.

Because the CPU can only increase the computational power, therefore:

When dealing with IO-intensive tasks, you should use multithreading

When dealing with computationally intensive tasks, you should use multi-process

the Gil schematic diagram

Explanation: The execution of the PY program, each time starts the Python interpreter first, the open memory space first will have the Python interpreter code, the other PY program code, is to give the interpreter the code to explain executes, then in the multi-threaded case, in order to interpret the level of data security, Each thread must have access to the Gil lock before it can execute, and the Gil Lock actually implements the thread safety of Python. (It is important to note that the garbage collection mechanism of Python is also a thread, which is turned on by default.) ）

Gil and mutual exclusion lock

Gil can only implement the data security of the interpreter level, for the user's own data inside the thread, still need to handle the shackles

　　

Analysis: # 1.1 threads to rob Gil Lock, that is to rob Execute permission     # 2. There must be a line enters upgradeable Rob Gil (called Thread 1), then start execution, once executed will get Lock.acquire ()     #3. It is very likely that thread 1 is not yet running. There is another thread 2 grab the Gil and start running, but thread 2 discovers that the mutex lock has not yet been released by thread 1, and then blocks and is forced to surrender the Execute permission, which releases the Gil    #4. Until thread 1 re-grabs the Gil, Begins the process of continuing execution from the last paused position until the mutex lock is normally released, and then the other thread repeats the 2 3 4 procedure

Gil and mutual exclusion lock analysis

#no Lock: Concurrent execution, fast, data insecure fromThreadingImportCurrent_thread,thread,lockImportOs,timedeftask ():GlobalNPrint('%s is running'%Current_thread (). GetName ()) Temp=N Time.sleep (0.5) n=temp-1if __name__=='__main__': N=100Lock=Lock () Threads=[] start_time=time.time () forIinchRange (100): T=thread (target=Task) Threads.append (t) t.start () forTinchthreads:t.join () stop_time=time.time ()Print('Master:%s n:%s'% (stop_time-start_time,n))" "Thread-1 is runningThread-2 is running ... THREAD-100 is running master: 0.5216062068939209 n:99" "#no Lock: No lock part concurrent execution, lock part serial execution, slow, data security fromThreadingImportCurrent_thread,thread,lockImportOs,timedeftask ():#code that is not locked and runs concurrentlyTime.sleep (3)    Print('%s start to run'%Current_thread (). GetName ())GlobalN#Lock code serial runlock.acquire () temp=N Time.sleep (0.5) n=temp-1lock.release ()if __name__=='__main__': N=100Lock=Lock () Threads=[] start_time=time.time () forIinchRange (100): T=thread (target=Task) Threads.append (t) t.start () forTinchthreads:t.join () stop_time=time.time ()Print('Master:%s n:%s'% (stop_time-start_time,n))" "Thread-1 is runningThread-2 is running ... THREAD-100 is running master: 53.294203758239746 n:0" "#Some students may have doubts: since the lock will let the operation into serial, then I immediately after start to use join, do not have to lock Ah, is also a serial effect AH#yes: Using Jion immediately after start will certainly turn the execution of the 100 tasks into serial, without a doubt, the result of N is certainly 0, is safe, but the problem is#join immediately after start: All the code within the task is executed serially, while the lock-only part that modifies the shared data is serial#single from the security aspects of the data, both can be achieved, but it is clear that the lock is more efficient. fromThreadingImportCurrent_thread,thread,lockImportOs,timedeftask (): Time.sleep (3)    Print('%s start to run'%Current_thread (). GetName ())GlobalN Temp=N Time.sleep (0.5) n=temp-1if __name__=='__main__': N=100Lock=Lock () start_time=time.time () forIinchRange (100): T=thread (target=Task) T.start () t.join () Stop_time=time.time ()Print('Master:%s n:%s'% (stop_time-start_time,n))" "Thread-1 start to runThread-2 start to run ... Thread-100 start to run Master: 350.6937336921692 n:0 #耗时是多么的恐怖" "

the difference between a mutex and a join

Process pool and thread pool

Why use ' pool ':

Use pools to limit the number of concurrent tasks and limit our computers to perform tasks concurrently in a way that is affordable to them

When to use a process pool: concurrent tasks are computationally intensive

When to use the thread pool: concurrent tasks are IO intensive

Grammar

The Concurrent.futures module provides a highly encapsulated asynchronous calling interface Threadpoolexecutor: Thread pool, which provides asynchronous invocation Processpoolexecutor: Process pool, providing asynchronous invocation

Process Pool Instance

  fromConcurrent.futuresImportProcesspoolexecutor,threadpoolexecutorImportTime,os,randomdefTask (x):Print('pick -up from%s'%os.getpid ()) Time.sleep (Random.randint (2,5))     returnX**2if __name__=='__main__': P=processpoolexecutor ()#The number of processes that are turned on by default is the number of CPU cores      forIinchRange (20): P.submit (task,i)

Thread Pool Instance

 fromConcurrent.futuresImportProcesspoolexecutor,threadpoolexecutorImportTime,os,randomdefTask (x):Print('pick -up from%s'%x) time.sleep (Random.randint (2,5))    returnX**2if __name__=='__main__': P=threadpoolexecutor (4)#the number of threads that are turned on by default is the CPU's core count    #Alex, Wupech, Yang Li, Wu Chen Taro, Zhang San     forIinchRange (20): P.submit (task,i)

Blocking and non-blocking (refers to two operational states of a program)

Blocking: Blocking occurs when an IO is encountered, the program stops in place once it encounters a blocking operation, and immediately releases CPU resources

Non-blocking (ready or running): No IO operation, or some means to let the program even when the IO operation will not stop in place, you can continue to perform other operations, to maximize the CPU

Synchronous and asynchronous refer to two ways of submitting a task

Synchronous invocation: After the task has been submitted, it waits in place until the task has finished running, and gets the return value of the task before continuing to execute the next line of code,

Asynchronous invocation: After the task is committed, not waiting in place, directly executing the next line of code, in the end can code each time the return value of the task

Gil Global interpreter lock and process pool. Thread pool