Python has GIL to ensure simultaneous operations on related objects. Why do we need to perform thread synchronization? Is it because related lock mechanisms and queue mechanisms are also required for multithreading at the virtual machine level? What is the principle of this mechanism? Are there other similar examples? In Python, GIL ensures the number of references to a variable. However, when multiple threads use the same resource, such as sys. stdout. In this case, thread synchronization is required to ensure that resource access does not conflict. Does GIL provide protection for similar resources? Python has GIL to ensure simultaneous operations on related objects. Why do we need to perform thread synchronization? Is it because related lock mechanisms and queue mechanisms are also required for multithreading at the virtual machine level? What is the principle of this mechanism? Are there other similar examples? In Python, GIL ensures the number of references to a variable. However, when multiple threads use the same resource, such as sys. stdout. In this case, thread synchronization is required to ensure that resource access does not conflict. Does GIL provide protection for similar resources? Reply: GIL is just like a method that used to simulate multithreading by a single-core CPU continuously allocating time slices. Why should I use a lock to write multiple threads at that time? This is a waste on the Internet, but I thought about it for a while.
Think about this situation on your own.
Thread AB simultaneously operates list
The [0] Initial Value of list is 0.
Thread A operates 100 times
List [0] + = 1
Thread B operates 100 times
List [0] + = 1
When thread A operates on list [0]
List [0] is 0. It is switched to thread B before thread A completes the plus one operation.
In the eyes of thread B,
The value of list [0] is still 0, so add one.
Switch back to thread A and continue the unfinished add-on operation.
Did you find it !!! Each thread AB adds one to list [0]. The expected result is 2, but the result is still 1.
The Python list is not completely thread-safe.
So it's time to add a thread lock.
Why does GIL need to be used with the thread lock?
With GIL, it is easy to provide concurrency. The Interpreter only needs to compute the running time of each thread.
Once the time reaches, the thread is frozen, and memory management is very simple.
Wait, you still have no explanation. If I have locked the thread, why is it still restricted by GIL?
Python, which has always been in line with human intuition, has a very intuitive mechanism.
Variable a of Py is not actually a variable of C compiling language.
Python maintains a dictionary and stores the pointer of a and corresponding values.
In the words of a hacker in a dark Python, Python tries to use a dictionary to hold the world ..
True Multithreading
Maintenance of this dictionary will be complicated.
Multiple Threads operate on a dictionary at the same time. Python is proud of its dictionary performance, and it is estimated that it is not that strong.
That is to say, the powerful performance of the Python dictionary is based on thread insecurity.
The location of the dictionary in Python is so important. A slow dictionary will seriously slow down the speed of interpretation of Python.
Multi-threaded operations on multiple independent dictionaries. synchronization is still required.
Why not use multi-process? This is the mainstream view of the community.
In theory, the thread cost is lower, but the code is completely invisible. The role of GIL is: for an interpreter, only one thread can execute bytecode. Therefore, only one bytecode is executed every moment. GIL ensures that bytecode is thread safe.
However, if you have an operation such as x + = 1, this operation requires multiple bytecodes operations. During the execution of multiple bytecodes operations, you may change the thread halfway, in this case, data races occurs.
For example, this guy has many bytecodes:
>>> dis.dis(lambda x: x+1) 1 0 LOAD_FAST 0 (x) 3 LOAD_CONST 1 (1) 6 BINARY_ADD 7 RETURN_VALUE
Https://www.youtube.com/watch? V = ph374fj1_pe
Gil controls bytecode and the lock controls python code. Is the granularity different? For example, if the code controlled by the lock is compiled into 101 bytecode, when the thread executes the 101 bytecode, the cpu will be used by other threads (by default, the python scheduling thread is scheduled once with 100 bytecode)
-- "Python source code analysis" GIL is a global interpreter lock. GIL ensures that there is always a Python (CPython implementation) thread running under the same time segment. Therefore, even multiple processes are executed sequentially. In this way, multi-threaded concurrency becomes meaningless.
- The thread has a time slice under GIL.
- If the thread in the time slice fails to operate the data, the data has been modified by another thread when the next time slice arrives, and the obtained data is not the desired data.
- The synchronization and mutex of threads solve the correctness of data access between threads, while GIL implements only one thread in the current Python interpreter. The two are different concepts.
