#thread #executor #task-queue

executors

一组高性能任务执行器

15 个版本 (8 个重大变更)

0.9.0 2021 年 4 月 5 日
0.8.0 2020 年 10 月 28 日
0.7.0 2020 年 7 月 13 日
0.6.0 2020 年 2 月 20 日
0.3.0 2017 年 12 月 19 日

#333并发

Download history 212/week @ 2024-03-11 201/week @ 2024-03-18 206/week @ 2024-03-25 311/week @ 2024-04-01 205/week @ 2024-04-08 204/week @ 2024-04-15 217/week @ 2024-04-22 201/week @ 2024-04-29 91/week @ 2024-05-06 96/week @ 2024-05-13 98/week @ 2024-05-20 78/week @ 2024-05-27 92/week @ 2024-06-03 75/week @ 2024-06-10 83/week @ 2024-06-17 81/week @ 2024-06-24

343 每月下载
用于 7 个 crate (2 个直接)

MIT 许可证

160KB
3.5K SLoC

此 crate 提供了一组任务执行器,它们都实现了 Executor trait。

通用示例可以在 Executor trait 文档中找到,每个实现模块都有特定的示例。

Crate 功能标志

以下 crate 功能标志可用。它们在您的 Cargo.toml 中配置。

  • threadpool-exec (默认)
  • cb-channel-exec (默认)
  • workstealing-exec (默认)
  • defaults (默认)
    • 使用 num_cpus 确定池大小来生成默认实现。
  • ws-timed-fairness (默认)
    • 此功能标志决定了 crossbeam_workstealing_pool 中本地和全局队列之间的公平机制。
    • 如果启用该标志,公平性基于时间。全局队列将每 100 毫秒检查一次。
    • 如果没有该标志,公平性基于计数。全局队列将每 100 个本地工作检查一次。
    • 您应该选择哪一个取决于您的应用程序。
    • 基于时间的公平性是在外部调度作业的延迟和整体吞吐量之间的折衷。
    • 基于计数的将严重依赖于您的作业的典型长度,但计数比检查时间便宜,因此可以导致更高的吞吐量。
  • ws-no-park
    • 禁用 crossbeam_workstealing_pool 的线程停车。
    • 这通常对性能有害,因为空闲线程会不必要地占用CPU资源。
    • 然而,对于与外部资源(例如,I/O)的非常敏感的延迟交互,这可以减少整体作业延迟。
  • 线程固定
    • 允许池线程固定到特定的核心。
    • 这可以在线程睡眠后唤醒时减少缓存无效化开销。
    • 然而,如果您的核心需要其他进程,如果固定的核心在唤醒时间不可用,也可能引入额外的调度延迟。
    • 请谨慎使用。
  • numa-aware
    • 做出内存架构感知的决策。
    • 具体来说,当前此设置仅影响 crossbeam_workstealing_pool
    • 当启用时,工作窃取将通过内存邻近性发生。
    • 也就是说,工作量过小的线程将首先尝试从内存接近的其他线程窃取工作,然后再尝试更远的线程。
  • 产生指标
    • 此crate中提供的每个执行器都可以使用metrics crate产生指标。
    • 指标是 executors.jobs_executed“总共执行了多少作业?”)和 executors.jobs_queued“当前有多少作业正在等待执行?”)。
    • 并非所有执行器都产生所有指标。
    • 警告:收集这些指标通常会有严重的性能影响。您只有在作业本身已经相当大(例如在毫秒范围内)的情况下才应考虑在生产中使用此功能。

依赖项

~1.4–2.5MB
~52K SLoC