WARNING: This article may be obsoleteThis post was published in 2022-03-08. Obviously, expired content is less useful to users if it has already pasted its expiration date.
This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
复习多线程相关
并发，并行，串行，异步，同步，多线程，进程，线程：🔗 [2022-01-26 - Truxton's blog] https://truxton2blog.com/2022-01-26/
python多线程相关
🔗 [python - What is the difference between ProcessPoolExecutor and ThreadPoolExecutor? - Stack Overflow] https://stackoverflow.com/questions/51828790/what-is-the-difference-between-processpoolexecutor-and-threadpoolexecutor
python的多线程有的时候会被称为“伪多线程”，这是因为python使用了GIL：🔗 [为什么有人说 Python 的多线程是鸡肋呢？ - 知乎] www.zhihu.com/question/23474039/answer/269526476
此外在上面的链接里还有另一个简介回答：
IPC共享内存
🔗 [行程間通訊 - 维基百科，自由的百科全书] https://zh.wikipedia.org/wiki/行程間通訊
CPU时间片
🔗 [cpu时间片的概念 - 简书] https://www.jianshu.com/p/44585830f009
哲学家就餐问题 / Dining philosophers problem
🔗 [哲学家就餐问题 - 维基百科，自由的百科全书] https://zh.wikipedia.org/zh-hans/哲学家就餐问题
OCR辅助查找工具
ProcessPoolExecutor runs each of your workers in its own separate child process. 57 ThreadPoolExecutor runs each of your workers in separate threads within the main process. The Global Interpreter Lock (GIL) doesn’t just lock a variable or function; it locks the entire interpreter. This means that every builtin operation, including things like listodicts[3] [‘spam’] = eggs is automatically thread-safe. But it also means that if your code is CPU-bound (that is, it spends its time doing calculations rather than, e.g., waiting on network responses), and not spending most of its time in an external library designed to release the GIL (like NumPy), only one thread can own the GIL at a time. So, if you’ve got 4 threads, even if you have 4 or even 16 cores, most of the time, 3 of them will be sitting around waiting for the GIL. So, instead of getting 4x faster, your code gets a bit slower. Again, for I/O-bound code (e.g., waiting on a bunch of servers to respond to a bunch of HTTP requests you made), threads are just fine; it’s only for CPU-bound code that this is an issue. Each separate child process has its own separate GIL, SO this problem goes away-even if your code is CPU-bound, using 4 child processes can still make it run almost 4x as fast. But child processes don’t share any variables. Normally, this is a good thing -you pass (copies of) values in as the arguments to your function, and return (copies of) values back, and the process isolation guarantees that you’re doing this safely. But occasionally (usually for performance reasons, but also sometimes because you’re passing around objects that can’t be copied via pickle), this is not acceptable, so you either need to use threads, or use the more complicated explicit shared data wrappers in the multiprocessing module. Share Improve this answer Follow answered Aug 13, 2018 at 19:12 abarnert 220V 29 551 • 621在python的原始解释器CPython中存在着GIL (Global Interpreter Lock，全局解释器锁），因此在解释执行python代码时，会产生互斥锁来限制线程对共享资源的访问，直到解释器遇到/O操作或者操作次数达到一定数目时才会释放GIL。 所以，虽然CPython的线程库直接封装了系统的原生线程，但CPython整体作为一个进程，同一时间只会有一个获得GIL的线程在跑，其他线程则处于等待状态。这就造成了即使在多核CPU中，多线程也只是做着分时切换而已。 不过muiltprocessing的出现，已经可以让多进程的python代码编写简化到了类似多线程的程度了。
