C++20并行算法中的异常处理与传播机制

1. 项目概述：并行算法中的异常传播挑战

在C++20引入std::ranges后，算法并行化变得前所未有的简洁，但当异常在并行执行环境中抛出时，事情就变得复杂起来。想象一下，当8个线程同时处理数据范围时，其中3个线程突然抛出异常——此时程序该终止哪些线程？如何收集所有异常？未完成的任务该如何处理？这正是现代C++并发编程中最棘手的场景之一。

传统单线程异常处理中，我们只需简单的try-catch块就能捕获异常。但在并行世界，异常可能在任何工作线程中爆发，而主线程可能正在处理其他任务。更复杂的是，标准库的并行算法（如std::for_each的并行版本）会隐式管理线程池，开发者甚至无法直接访问这些工作线程。我曾在一个图像处理项目中遭遇这样的困境：当某个工作线程因无效像素数据抛出异常时，程序竟然默默地吞掉了部分异常，导致最终结果出现难以追踪的偏差。

2. 核心机制解析

2.1 std::ranges并行执行模型

std::ranges的并行算法通过执行策略（execution policy）控制并行度。以下是最常用的三种策略：

cpp复制// 顺序执行（传统单线程）
std::ranges::sort(execution::seq, data);

// 并行执行（自动线程管理）
std::ranges::sort(execution::par, data); 

// 向量化并行（SIMD指令级）
std::ranges::sort(execution::par_unseq, data);

当使用execution::par时，标准库会创建线程池分割数据范围。关键在于：每个工作线程处理的是原始范围的子范围，而非单个元素。这意味着异常可能在任何子范围的处理过程中抛出。

2.2 异常传播的连锁反应

当并行算法中发生异常时，标准库会触发以下连锁反应：

1. 立即取消所有未开始的任务
2. 对已运行的任务发出中断信号（通过内部取消令牌）
3. 等待所有正在执行的任务完成或响应中断
4. 将首个遇到的异常重新抛出到调用线程

这种机制看似合理，但存在两个致命缺陷：

• 只有第一个异常能被捕获，后续异常被静默丢弃
• 中断是协作式的，不响应中断的任务会继续执行完

cpp复制try {
    std::rang