`timed_thread_context`: an operation stopped just before the context is destroyed never completes

已關閉
  • 哪裡不對？
#2,334 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 2 天內回覆

已經有一個關聯 PR 被合併了。

  • #2335 來自 @workingBanana —— 已合併

評估

難度
4/5
預估耗時
3-5 天
新手友好度
20/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
cpp
領域
backend

研究方向

The bug is in timed_thread_context::run() in the timed thread scheduler header that the reproducer includes (exec/timed_thread_scheduler.hpp). Read the loop that drains command_queue_ and the stop branch that closes submissions and calls set_stopped_() on the heap. Build the reproducer, which should report 1000 of 1000 lost completions. Done means every operation completes exactly once after a stop request races with destruction. Linked PR #2335 already proposes a fix, so check it before starting.

由索引模型根據 Issue 內容生成。

描述

Summary

When timed_thread_context::run() sees stop_requested_, it closes submissions, stops the operations in the heap and exits, without draining command_queue_ again:

while (true) {
  while (command_type* op = command_queue_.pop_front()) { ... }  // the only drain
  ...
  cv_.wait_until(lock, deadline, [this] { return ready_ || stop_requested_; });
  if (stop_requested) {
    // close submissions (CAS n_submissions_in_flight_ to context_closed)
    // set_stopped_() on every operation in heap_
    break;  // commands pushed since the drain above are never processed
  }
}

A stop request from another thread raises the operation's ref_count_ from 1 to 2 and queues a stop command. If the context is destroyed before its thread drains that command, the heap pass only drops the count to 1. The stop command, which would drop it to 0 and call set_stopped, is never processed. So the receiver gets neither set_value nor set_stopped, and anything waiting on it (sync_wait, async_scope::on_empty(), ...) hangs.

A schedule command queued after the last drain is lost the same way: it is never inserted into the heap, so the heap pass doesn't stop it.

This breaks the context's own shutdown guarantee: the destructor stops the operations in the heap, and submissions made after close complete inline with set_stopped.

It seems that the current behavior violates https://eel.is/c++draft/exec.async.ops#8: “After its start operation has begun executing, exactly one completion operation shall execute.”

Reproducer

#include <exec/timed_thread_scheduler.hpp>
#include <stdexec/execution.hpp>

#include <atomic>
#include <chrono>
#include <cstdio>
#include <optional>
#include <thread>

namespace ex = STDEXEC;

struct env {
  ex::inplace_stop_token token;
  auto query(ex::get_stop_token_t) const noexcept { return token; }
};

struct receiver {
  using receiver_concept = ex::receiver_tag;
  std::atomic<int>* completed;
  ex::inplace_stop_token token;
  void set_value() noexcept { completed->store(1); }
  void set_stopped() noexcept { completed->store(2); }
  env get_env() const noexcept { return {token}; }
};

int main() {
  int lost = 0;
  const int runs = 1000;
  for (int i = 0; i < runs; ++i) {
    std::atomic<int> completed{0};
    ex::inplace_stop_source source;
    std::optional<exec::timed_thread_context> ctx{std::in_place};
    auto op = ex::connect(exec::schedule_after(ctx->get_scheduler(), std::chrono::hours(1)),
                          receiver{&completed, source.get_token()});
    ex::start(op);
    std::this_thread::sleep_for(std::chrono::microseconds(200)); // the operation reaches the heap
    source.request_stop(); // queues a stop command
    ctx.reset();           // request_stop() + join, usually before the thread drains the command
    if (completed.load() == 0) { // the thread has exited, so nothing will ever complete it
      ++lost;
    }
  }
  std::printf("receiver never completed in %d of %d runs\n", lost, runs);
  return lost == 0 ? 0 : 1;
}

The output will be: receiver never completed in 1000 of 1000 runs. It should be 0 of 1000.

Suggested fix: https://github.com/NVIDIA/stdexec/pull/2335

主要語言
C++
星號
2.5k
分支
285
平均合併
2 天 5 小時
30 天內合併 PR
82

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

NVIDIA/stdexec 的其他 Issue

查看 NVIDIA/stdexec 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。