异构任务调度的核心是显式资源绑定策略，cpu线程仅负责下发、同步和数据搬运，gpu任务必须由对应runtime在设备上下文中执行，混合调度本质是cpu侧协调多个异步队列而非统一任务池。
异构任务调度的核心不是框架，是显式资源绑定策略
直接用 std::thread 或 std::async 调 GPU 任务必然失败——GPU 计算不能靠 C++ 标准库调度。关键在于：CPU 线程只负责下发、同步、数据搬运；GPU 任务必须由对应 runtime（如 CUDA、HIP、OpenCL）在设备上下文中执行。所谓“混合调度”，本质是 CPU 侧协调多个异步队列（cudaStream_t、hipStream_t、cl_command_queue），而非统一抽象成一个任务池。
- 不要试图写一个通用
TaskScheduler模板类去统一 dispatch__global__和普通函数——它们的调用协议、内存可见性、错误传播机制完全不同 - 每个 GPU 设备需独立管理自己的 stream 和 event，跨设备任务依赖必须显式用
cudaEventSynchronize或hipEventSynchronize，不能依赖 CPU 线程等待 - CPU 侧任务若需访问 GPU 显存（如 pinned memory 上的
float*），必须用cudaHostRegister或hipHostRegister锁页，否则 memcpy 性能暴跌
如何让 CPU 任务和 GPU 任务真正并发执行？
常见错误是把 cudaMemcpyAsync 放在主线程里，然后立刻 cudaStreamSynchronize——这等于串行。真正并发的前提是：CPU 工作和 GPU 工作在逻辑上无数据依赖，且 GPU 操作全部异步化。
- GPU 计算启动后，CPU 应立即进入下一段计算（比如预处理下一帧数据），而不是等
cudaStreamQuery - 避免在 GPU stream 中混用同步 API：
cudaMemcpy（同步）会阻塞整个 stream，必须全换成cudaMemcpyAsync并指定正确 stream - 使用
cudaStreamCreateWithFlags(..., cudaStreamNonBlocking)创建非阻塞流，否则默认流行为不可控，容易隐式同步 - 注意 pinned memory 分配开销：频繁
cudaMallocHost/cudaFreeHost比malloc慢数倍，应复用缓冲区
为什么 std::future + std::promise 不适合 GPU 任务完成通知？
std::future::wait 是 CPU 线程级阻塞，而 GPU 任务完成是设备事件驱动。用 std::promise 包裹 cudaStreamSynchronize 会导致线程空转或死锁——它无法响应 GPU 硬件中断。
- 正确做法是用
cudaEventRecord在 stream 中打点，再用cudaEventQuery非阻塞轮询（适用于低延迟场景），或用cudaEventSynchronize配合独立监控线程（适用于长任务） - 如果非要封装成 future-like 接口，必须底层用
cudaEvent+std::condition_variable，不能直接 returnstd::async(...).get() - HIP 用户注意：
hipEvent行为与 CUDA 不完全一致，hipEventQuery在某些 AMD 驱动版本返回值含义不同，务必实测
混合调度中最容易被忽略的内存一致性陷阱
CPU 和 GPU 各自维护一套缓存层级，不加干预时，CPU 写入的 pinned memory 对 GPU 可能不可见，反之亦然。这不是 bug，是硬件设计使然。
立即学习“C++免费学习笔记（深入）”；
- 对 CPU 修改后要 GPU 读取的数据，必须调用
cudaHostSynchronize（或hipHostSynchronize）强制刷出 CPU cache - 对 GPU 修改后要 CPU 读取的数据，必须在 kernel 后插入
cudaStreamSynchronize或cudaEventSynchronize，不能只靠cudaMemcpyAsync返回就认为数据就绪 - 使用 Unified Memory（
cudaMallocManaged）看似省事，但缺省内存迁移策略在复杂访问模式下极易引发隐式同步，性能反而更差；仅在访问模式高度随机且数据集不大时考虑
异构调度最难的部分从来不是怎么发任务，而是怎么确认“此刻数据真的就绪了”。所有同步点都得落在硬件可验证的 event 或 stream barrier 上，任何“应该已经完成了”的假设都会在高负载下暴露。
