【问题标题】:Work stealing and deques工作窃取和双端队列
【发布时间】:2015-01-07 23:43:16
【问题描述】:

为什么我们需要一个双端队列来窃取工作? (例如在 Cilk 中)所有者在顶部工作,小偷从底部偷窃。为什么有用?

我们可能有多个窃贼从底部偷窃。那么,我们不需要锁吗? 我在某处读到较大的作业(例如在树中创建)被添加到底部。因此,从底层偷窃更有效(沟通更少,因为窃贼通过偷窃他们变得更加忙碌)。是这样吗?

【问题讨论】:

    标签: parallel-processing task-parallel-library deque work-stealing


    【解决方案1】:

    THE 协议的详细信息在“Cilk-5 多线程语言的实现”的第 5 节中描述,可从 MIT 获得:http://supertech.csail.mit.edu/papers/cilk5.pdf

    【讨论】:

      【解决方案2】:

      你不需要一个双端队列来窃取工作。使用并发数据结构来存储任务池是可能的(人们已经这样做了)。但问题是worker的push/pop操作和小偷的窃取请求都必须同步。

      由于预计窃取是相对罕见的事件,因此可以设计一种数据结构,以便在窃取尝试期间主要执行同步,即使在从数据中弹出项目可能存在冲突时也是如此结构体。这正是 Cilk 中使用双端队列的原因 - 以最大限度地减少同步。 Worker 将自己的 deques 视为堆栈,从底部推送和弹出线程,但将另一个忙碌的 worker 的 deque 视为队列,只要它们没有本地线程要执行,就只从顶部窃取线程。由于窃取操作是同步的,因此多个小偷试图从同一个受害者那里窃取是可以的。

      将较大的作业添加到底部是分而治之的算法中常见的,但不是全部。有各种各样的策略可以在偷窃期间做什么。偷一个任务,几个任务,一半任务,等等。这些变体中的每一个都适用于某些应用程序,而在其他应用程序中则不太适用。

      【讨论】:

      • 感谢您的回答。我同意其中的大部分。只有“因为抢断被认为是相对罕见的事件”部分:在 fork-join 模型中不是这样。整个模型基于偷窃。大师级的工人创造了工作,而其他人几乎一直在偷窃。对吗?
      • @TOWI_Parallelism,是的,有些应用程序的窃取会相对更频繁。但是,在窃取后的许多应用程序中,执行任务的工作人员也会产生新任务。这些任务被添加到本地队列中。所以工人不需要经常从主线程窃取。
      【解决方案3】:

      工作窃取实际上确实需要一个双端队列。在原始论文中,他们证明了在具有 P 个处理器的系统上使用的最大内存。限制由任何堆栈的最大大小乘以处理器数量给出。这实际上只有遵循忙叶定理才有可能。此外,工作窃取的另一个重要特征是: 当一个 worker 生成一个 spawn 时,它会立即将 spawner 保存在 deque 上并开始在 child 上工作。有关他们的证明的更多信息,请阅读他们的原始论文,他们在其中解释了我所说的一切。 http://supertech.csail.mit.edu/papers/steal.pdf

      工作窃取双端队列访问中的并发控制与工作窃取调度程序无关,事实上,已经进行了很多研究以从双端队列中删除锁(通过使用无锁结构)以及尽可能减少可能的记忆障碍。例如在这篇论文中(如果无法访问,我很抱歉,但无论如何你都可以阅读摘要来了解这个想法):http://dl.acm.org/citation.cfm?id=1073974 作者创建了一个新的双端队列来改进上述方面。

      偷窃是从工人没有工作的一侧进行的,可能有几个原因: 由于双端队列充当每个工人(双端队列的所有者)的堆栈,因此“更大”的作业应该在它之上(正如您可以通过阅读论文来理解的那样)。当我说更大时,我的意思是那些可能会有更多的计算要做。此外,另一个重要方面是这样做(从双端队列所有者的对面工作端窃取)减少了争用,因为在某些新双端队列中,受害者和窃贼可能同时在同一个双端队列上工作。

      【讨论】:

      • 如果您还有任何问题,请告诉我,这是我的研究领域,所以我很乐意尽我所能帮助您:)
      • 感谢 guilhermemtr!这对于 fork-join 模型是绝对正确的。对于某些模型,不需要双端队列,例如当您在编译时定义所有任务时。我就是这么看的。如果你不同意我们来讨论..
      • 确实如此。但是请注意,对于在运行时生成任务的模型,使用双端队列(或任何其他允许保证忙叶属性的数据结构(如原始论文中所述))是支点。所以不能使用队列(例如)。
      猜你喜欢
      • 2016-01-19
      • 2011-01-07
      • 2018-07-02
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-05-06
      • 1970-01-01
      相关资源
      最近更新 更多