为何同步续体不再同步执行？TPL实现ManualResetEvent相关疑问

在Stephen Toub的文章里，用TPL实现的AsyncManualResetEvent的Set方法代码如下：

public void Set()
{
    var tcs = m_tcs;
    Task.Factory.StartNew(
        s => ((TaskCompletionSource<bool>)s).TrySetResult(true),
        tcs,
        CancellationToken.None,
        TaskCreationOptions.PreferFairness,
        TaskScheduler.Default);
    tcs.Task.Wait();
}

文中提到tcs.Task.Wait()「会阻塞直到任务本身完成（不包含任务的同步续体）」，疑问点在于：为何该调用不会阻塞同步续体？是什么阻止了等待tcs.Task完成的Task的同步续体同步执行？

核心解释 #

1. Task.Wait()的本质 #

Task.Wait()的唯一作用是等待目标Task进入完成状态（RanToCompletion/Faulted/Canceled），它完全不关心绑定到该Task的续体（无论是同步还是异步）是否执行完毕。只要TrySetResult(true)调用完成，tcs.Task就会立刻标记为完成状态，此时Wait()就会解除阻塞直接返回——和续体的执行进度完全无关。

2. 同步续体的执行线程 #

这里的TrySetResult是被放到线程池线程上执行的（Task.Factory.StartNew默认使用线程池）。当线程池线程调用TrySetResult时，任何标记为ExecuteSynchronously的同步续体，会尝试在这个线程池线程上同步执行。
而调用Set()方法的线程（也就是调用Wait()的线程）是完全独立的另一个线程，两者不存在互斥等待的关系：线程池线程在执行续体，调用Wait()的线程在Task完成后直接继续执行，彼此不会阻塞。

3. 死锁风险的规避 #

如果TrySetResult是在调用Wait()的线程上直接执行，同步续体可能会在同一个线程上执行，若续体中存在等待操作则可能触发死锁。但这段代码特意把TrySetResult放到线程池线程执行，相当于把"触发续体"和"等待Task完成"的操作拆分到两个独立线程，从根源上避免了同步续体与Wait()线程互相阻塞的可能。

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