今天听了猫大直播时对Fiber的讲解。再结合这几天看过的同步上下文知识。说一下我对Fiber的看法。如果哪里理解错了，也请大家帮我指出来，不然孩子会在错误的理解上一路走到黑。

ThreadPoolScheduler

负载均衡

假如我们有四个核，可以分配出10个线程。现在我们创建了1000个Fiber。那线程调用Fiber的逻辑是：

计算自己一次处理Fiber的任务数量
从id队列中取出对应的Fiber1，执行Fiber1的任务。
Fiber1执行完之后，再从id队列中取出下一个Fiber2执行。
如果id队列空了，线程休息。

这样设计对负载均衡是友好的。假如线程1处理的Fiber1很耗时，则线程1被卡住，但是线程2，线程3可以继续从id队列中取出Fiber去执行。

如果我们1000个Fiber，在创建的时候就分配给指定的线程。类似这样，线程1处理Fiber1-100，线程2处理Fiber101-200,以此类推，最后线程10处理Fiber901-1000。

那假如我1000个fiber里，就Fiber1特别耗时，那我线程1在处理Fiber1的时候，Fiber2-100，就得等待Fiber1执行完才会被处理到。这样，就会导致不同线程分配不均的情况，毕竟，我们在开发的时候，并不知道每个Fiber的耗时，不能够说我知道Fiber1很耗时，那我线程1就只负责Fiber1和其他10个简单的Fiber。

SynchronizationContext.SetSynchronizationContext

那为什么每次调用Fiber.Update之前，都要先SynchronizationContext.SetSynchronizationContext(fiber.ThreadSynchronizationContext);呢。

可以先看一下[SynchronizationContext](app://obsidian.md/SynchronizationContext)。

在ET中，因为是多线程开发，所以我们需要考虑多线程的安全问题。
例如：（AI举例）

竞态条件（Race Condition）：当多个线程同时访问和修改共享数据时，可能会导致竞态条件。为了避免竞态条件，需要使用同步机制（如锁、互斥量、信号量等）来保护共享数据的访问。

死锁（Deadlock）：当多个线程相互等待对方释放资源时，可能会发生死锁。为了避免死锁，需要避免循环等待和合理地管理资源的获取和释放顺序。

数据共享和同步：在多线程编程中，共享数据需要进行适当的同步，以确保线程安全。可以使用锁、互斥量、条件变量等同步机制来保护共享数据的访问。

线程安全性：需要注意并发环境下的线程安全性。确保多个线程可以正确地访问和修改共享数据，而不会导致不一致或错误的结果。

线程间通信：在多线程编程中，线程之间需要进行通信和协调。可以使用线程间的信号量、事件、条件变量等机制来实现线程间的通信。

上下文切换开销：多线程编程会引入上下文切换的开销。如果线程数量过多或上下文切换频繁，可能会导致性能下降。需要合理地管理线程数量和调度策略，以提高性能。

异常处理：在多线程编程中，需要注意异常处理。确保及时捕获和处理异常，以避免线程终止或未处理的异常导致程序崩溃。

那我们直接让同一个Fiber的任务，同时只能让一个线程去处理，就可以做到线程同步，也不会有线程安全的问题。

而在 [SynchronizationContext](app://obsidian.md/SynchronizationContext)中，我们知道，当异步方法完成时，如果想返回指定线程去执行，可以通过SynchronizationContext的Post方法。

我们前面说到，ET的Fiber是由不同线程去获取并处理的，所以同一时间，Fiber具体在哪个线程，我们并不知道。可能我Fiber1在线程1发起的异步任务task1，等task1执行完之后，FIber1已经是在线程n上处理了。

这个时候，如果我不做额外处理，.Net的await/async，会把func1之后的逻辑，返回线程1去处理，因为默认的new SynchronizationContext()是与当前线程1关联的，当调用他的Post方法时，会在创建他时的线程1执行。但这时Fiber1是在线程2中处理的，这样，线程1和线程2同时在处理Fiber1，就容易引发线程的安全问题。

那ET是怎么处理这个问题的呢？

ET实现了一个自定义的 [ThreadSynchronizationContext](app://obsidian.md/ThreadSynchronizationContext),将需要返回指定线程执行的”回调“方法，存到一个线程安全的队列里。
然后在每个Fiber的LateUpdate当中，去处理这个队列里的"回调"。这样，能保证队列中的方法都是在同一线程当中去执行的。

那怎么让await Task.Run后面的"回调"，存进这个队列呢？

出现这个问题的原因是，我们在执行以下代码时

$$
await Task.Run(Action1) action2
$$

await的机制会将action2作为一个”回调“方法，存入一个SynchronizationContext实例的消息队列中，这个SynchronizationContext实例是哪来的呢？

它会先判断SynchronizationContext.Current是否为空，如果不为空，则消息存入SynchronizationContext.Current当中，如果为空，则会new一个新的SynchronizationContext，与当前线程关联。

那只要SynchronizationContext.Current不为空，在SynchronizationContext.Current发生改变前，是不是所有的"回调"就都会存入同一个SynchronizationContext当中啦？

所以在处理Fiber的任务前，先把当前线程的 SynchronizationContext.Current 设为Fiber.ThreadSynchronizationContext。

这就是`SynchronizationContext.SetSynchronizationContext(fiber.ThreadSynchronizationContext);`干的事。

这样，在处理Fiber的过程当中生成的所有的"异步回调"，都会存入 ThreadSynchronizationContext的队列里。

也就保证了，在同一个Fiber内产生的所有的”异步回调“，最后都会在Fiber的当前线程当中被执行。