Task内部为何要使用ManualResetEventSlim？

首先明确：这个ManualResetEventSlim并非用于线程池内部的工作项调度，而是为了支持外部线程同步等待Task完成的场景，具体细节如下：

1. 解决的核心问题：同步等待需求 #

当代码中调用task.Wait()、task.Result，或是使用Task.WaitAll()这类API时，调用线程（可能是主线程、非线程池工作线程）需要阻塞自己，直到目标Task执行完成。如果没有这个同步原语，等待线程只能通过循环检查IsCompleted属性来判断Task状态，这会导致CPU空耗，效率极低。ManualResetEventSlim就是用来让等待线程进入休眠状态，直到Task完成后被唤醒。

2. 同步的双方 #

它实现的是等待Task完成的外部线程与**执行Task的线程池工作线程（或其他执行Task的线程）**之间的同步：

• 执行线程在Task完成时，会触发这个事件的Set()操作；
• 所有等待该事件的外部线程会被唤醒，继续执行后续逻辑。

3. 选择ManualResetEventSlim的原因 #

这个类型是轻量级的同步原语，相比传统的ManualResetEvent有两个关键优势：

• 懒加载：从源码可见，CompletedEvent是在第一次被访问时才初始化的，避免了每个Task创建时就分配内核资源，节省了内存开销；
• 混合等待模式：短时间等待时会先使用用户态自旋锁，只有等待超时才会切换到内核态阻塞，大幅减少了内核态切换的性能损耗。

4. 和线程池调度的关系 #

线程池的队列调度（全局/本地队列分配工作项）是Task的异步执行调度逻辑，而ManualResetEventSlim是处理同步等待场景的补充机制——Task设计既支持异步无阻塞的使用方式（比如await），也支持同步阻塞的使用方式，这个同步结构就是为后者服务的。

从你贴出的源码也能看到细节：

• 初始化时会先判断Task是否已完成，如果是，直接创建已触发状态的事件；
• 如果初始化后Task才完成，会通过ContingentProperties.SetEvent()触发事件，避免等待线程死锁；
• 用Interlocked.CompareExchange处理并发初始化的情况，保证线程安全。

内容的提问来源于stack exchange，提问作者user22155685