多线程项目的Big-O

时间:2019-02-22 13:47:20

标签: multithreading time-complexity code-complexity

让我们假设我创建了一个有2个线程的项目。 其中的大O分别为 n! n ,并且它们同时运行。

当其中一个返回我想要的内容时,两个都停止了。 话虽如此,尽管其中一个线程的Big-O为 n!,但算法的复杂度为 O(n)是有意义的,我是吗?对吧?

P.S。我做了研究,但没有一个答案能满足我的需要,因为他们都谈论一个减少一半的问题(每个线程 O(n / 2)而不是 O(n )),而我想立即开始解决2个问题,但是当第一个问题完成时,两个问题都停止了。

1 个答案:

答案 0 :(得分:0)

对此的分析需要更加小心。


线程调度程序可能无法保证所有线程都将获得“合理的”执行时间。想象两个线程都从1开始计数,但是线程调度程序将线程A唤醒1步,然后将B唤醒1步,然后将A唤醒2步,然后将B唤醒1步,然后将A唤醒4步,依此类推

在这种情况下,线程A的工作量将比线程B的工作量大,这是因为调度程序将其分配给它的时间成倍增加。因此,如果线程B发出信号,要求线程A在B计数到n后停止,那么线程A将在计数到2 n -1之后停止。调度程序可能更加不公平,因此A的运行时间不能被n的 any 函数限制。

鉴于此,如果线程A选择在n之后终止自身!操作,则其运行时间只能由O(n!)来限制,因为我们无法保证线程B将完成其n个操作并在该时间内发送终止信号。 >


现在假设线程调度程序确实保证一个线程永远不会比某个线程受某个常量因素的青睐。在这种情况下,线程B完成O(n)步骤后,线程B中的算法将向线程A发送信号。由于线程A只能在同一时间完成O(n)个步骤(否则,它比线程B受到的好处要多一个常数),因此线程A将在O(n)时间终止。

也就是说,线程A中的算法正在检查信号并在接收到该信号时终止,这一事实意味着O(n!)不能推导为 tight 上限。只看线程A的作用即可因为它具有从外部接收到信号时要终止的指令。因此,至少没有矛盾。

相关问题