Python有了concurrent的话mutiprocessing和threading还有存在的意义吗？

Question

Python3.2中引入的concurrent非常的好用，只用几行代码就可以编写出线程池/进程池，并且计算型任务效率和mutiprocessing.pool提供的poll和ThreadPoll相比不分伯仲，而且在IO型任务由于引入了Future的概念效率要高数倍。

而threading的话还要自己维护相关的队列防止死锁，代码的可读性也会下降，相反concurrent提供的线程池却非常的便捷，不用自己操心死锁以及编写线程池代码，由于异步的概念IO型任务也更有优势。

既然如此，如果不是为了向下兼容2.x，是不是可以完全没有必要继续使用mutiprocessing和threading了？concurrent如此的优秀。

Answer 1

concurrent は確かに非常に便利で、主に ThreadPoolExecutor と ProcessPoolExecutor を提供します。マルチスレッド、マルチプロセス。しかし、同時実行は本質的にはスレッド化とマルチプロセッシングをカプセル化したものです。ソースコードを見ればわかります。
ThreadPoolExecutor は独自のタスクキューを提供するため、自分で記述する必要はありません。いわゆるスレッド プールは、現在のスレッド数と max_workers の定義されたサイズを比較するだけで、サイズが max_workers より小さい場合、タスクはタスクを実行するためのスレッドを作成できます。ソースコードが見れます

def _adjust_thread_count(self):

リーリー

そのため、自分でキューを管理する場合でも、Cocurrent は内部でキューを管理しており、それは単にユーザーのために書かれたものであるため、問題はありません。
デッドロックの問題に関しては、同時実行でもデッドロックの問題が発生する可能性があります。例を挙げて、実行して見てみましょう

リーリー

ProcessPoolExecutor も内部でマルチプロセッシングを使用します。マルチコアの特性を最大限に活かし、GILの制約を取り除くことができます。 ProcessPoolExecutor(max_workers=2) を定義する場合、max_workers は CPU コアの数よりわずかに大きく、大きすぎることはできないことに注意してください。 ProcessPoolExecutor は、タスク キューを維持するために call_queue を内部的に維持します。そのタイプは multiprocessing.Queue です。キューを管理するスレッドもあります。これはコカレントの最適化であると言えます。
詳細については、self._adjust_process_count() が実際にタスクを実行するプロセスを開始するので、_adjust_process_count をクリックすると一目でわかります。 self._queue_management_thread はキューを管理するスレッドです

リーリー つまり、同時実行はキューの維持やキュー スレッドの管理など、より優れた処理を独自に実行するため、心配する必要はありません。もちろん自分で実装することもできます。これは、同時実行を使用して実現できます。最悪の場合、追加の作業を自分で行う必要がありますが、これはスレッド化とマルチプロセッシングを使用して実現できます。コカレントは基本的にこれら 2 つのコアを使用するためです。もちろん、自分で車輪を再発明するのではなく、すぐに利用できるより優れたコカレントを直接使用できるのが最善です。したがって、どれを使用するかは個人の習熟度によって異なります。たとえば、私は python2 を使用しますが、同時実行は使用できません。スレッドを使用する必要がありました。

Answer 2

上記の人はすでに明確に述べていますが、少しだけ追加したいと思います。
Concurrent.future はスレッド/プロセスを管理するために非同期の概念を使用しますが、実際には非同期 IO をカプセル化していないため、前述の IO 効率は異なります。質問は実際には間違っています

Answer 3

同時実行はスレッドではなくコルーチンであり、2 つの概念です。