线程内的线程？(threads inside a thread?)

线程内的线程？(threads inside a thread?)

我想用pthread实现分而治之，但我不知道如果我在一个线程中创建更多的线程会发生什么。

根据我的理解，如果机器有一个2核处理器，它只能同时处理2个线程。 如果有超过2个线程，其他线程必须等待资源，所以如果我在创建更多线程的同时进行更深入的处理，实际上它可能不会增加算法的速度，因为只有2个线程可以在同一时间。

我在网上做了一些研究，似乎上层的线程可以不活动，只有最深层的线程保持活动。 如何实现这一目标？ 此外，如果面线保持不活动状态，它是否会影响底线？

I wanna implement divide and conquer using pthread, but I don't know what will happen if I create more threads in a thread.

From my understanding, if the machine has a 2-core processor, it can only process 2 threads at the same time. If there are more than 2 threads, other threads have to wait for the resources, so if I create more and more threads while I'm going deeper, actually it may not increase the speed of the algorithm since only 2 threads can be processed at the same time.

I do some research online and it seems the threads at upper level can be inactive, only the ones at the deepest level stay active. How to achieve this? Also if an upper thread stays inactive, does it affect the lower thread?

最满意答案

有两种基本类型：分离和可连接。

可连接的线程是您可以使用pthread_join等待（或访问结果）终止的线程。

使用比核心更多的线程可以帮助或伤害 - 取决于你的程序！ 通过多线程最小化或消除对资源的竞争通常是好的。 在程序中抛出太多的线程实际上可能会减慢进程速度。 但是，如果内核数量与线程数量匹配，并且其中一个线程正在磁盘IO上等待（如果其他进程中没有发生重大事件），则可能会有CPU空闲时间。

上层的线程可以不活动，只有最深层的线程保持活动状态。 如何实现这一目标？

使用可连接线程，您可以完成您概述的嵌套线程方法，这在几个教程中得到了证明。 基本流程是线程将创建一个或多个worker，并等待他们使用pthread_join退出。 然而，在大多数情况下，诸如任务和线程池等替代方案更可取。

尽管如此，这种方法不太适合执行，因为它与硬件和调度操作没有关系，特别是随着程序深度和宽度的增长。

如果面线保持不活动状态，是否会影响底线？

是。 然而，典型的问题是工作/线程不受限制。 使用你所描述的方法，很容易产生许多线程，并且对于必须在有限数量的内核上执行的工作具有不合理的大量线程。 因此，你的程序会浪费一堆时间上下文切换并等待线程完成。 创建许多线程也可以浪费/预留大量资源，尤其是在短暂和/或闲置/等待的情况下。

因此，如果我在深入时创建越来越多的线程，实际上它可能不会提高算法的速度，因为只能同时处理2个线程。

这表明使用这种方法创建线程是有缺陷的。 您可能需要创建一些线程，并使用基于任务的方法 - 每个线程都会请求并执行集合中的任务。 创建一个线程需要很多时间和资源。

There are two basic types: detached and joinable.

A joinable thread is one which you may wait for (or access the result of) termination using pthread_join.

Using more threads than there are cores can help or hurt -- depends on your program! It's often good to minimize or eliminate competition for resources with multithreading. Throwing too many threads at a program can actually slow the process down. However, you would likely have idle CPU time if the number of cores matches the thread count and one of the threads is waiting on disk IO (provided nothing significant is happening in other processes).

threads at upper level can be inactive, only the ones at the deepest level stay active. how to achieve this?

Using joinable threads, you can accomplish the nested thread approach you have outlined, and this is demonstrated in several tutorials. The basic flow is that a thread will create one or more workers, and wait for them to exit using pthread_join. However, alternatives such as tasks and thread pools are preferable in the majority of cases.

Nevertheless, it's unlikely that this approach is the best for execution, because it does not correlate (well) with hardware and scheduling operations, particularly as depth and width of your program grows.

if a upper thread stay inactive, won't affect the lower thread?

Yes. The typical problem, however, is that the work/threads are not constrained. Using the approach you have outlined, it's easy to spawn many threads and have an illogically high number of threads for the work which must be executed on a limited number of cores. Consequently, your program would waste a bunch of time context switching and waiting for threads to complete. Creating many threads can also waste/reserve a significant amount of resources, especially if they are short-lived and/or idle/waiting.

so if i create more and more threads while im going deeper, actually it may not increase the speed of the algorithm since only 2 threads can be processed at the same time.

Which suggests creating threads using this approach is flawed. You may want to create a few threads instead, and use a task based approach -- where each thread requests and executes tasks from a collection. Creating a thread takes a good bit of time and resources.