我将一些代码从 winforms 控制对象移动到一个单独的对象，以获得更好的模块化。但是，有一些对发出回调的外部对象的调用，我无法控制这些回调，并且可以从作为主 UI 线程的不同线程触发这些回调。为了避免这种情况，我使用众所周知的 BeginInvoke 方案来检查是否应将调用转移到主 UI 线程。
当我现在将此代码移至分离的对象时，我不再需要 Winforms 引用。我可以处理 Control 对象以仍然确保所有内容都在同一个线程中运行。但我宁愿有一个通用机制，它的作用与确保 Threadconext 完全相同，其中例如创建对象或调用特定入口函数也用于发出的后续调用，例如通过外部回调。
如何才能最轻松地实现这一目标？
示例:
public class Example
{
ThreadedComponent _Cmp = new ThreadedComponent();
public Example()
{
_Cmp.ThreadedCallback += new ThreadedComponent.CB(Callback);
}
public void StartFunction()
{
// called in ThreadContextA
_Cmp.Start();
}
void Callback(Status s)
{
// is called in ThreadContextB
if(s == SomeStatus)
_Cmp.ContinueFunction(); // must be called in ThreadContextA
}
}
为了澄清
ContinueFunction 必须从同一个 ThreadContext 调用，就像调用 StartFunction 一样。这不一定是 UI 线程，但目前它当然是按钮处理程序。
最佳答案
没有“通用”方案，您的类无法对它在哪个线程上使用以及哪个对象可以提供您需要的 BeginInvoke() 方法做出很多假设。从以下选项之一中进行选择:
根本没有帮助，只是记录可以在工作线程上引发事件。无论 GUI 层中存在什么代码，当然总能在需要时弄清楚如何使用 BeginInvoke()。
允许客户端代码通过类构造函数传递 Control 对象。您可以存储它并调用它的 BeginInvoke() 方法。这可行，但不是很漂亮，因为您的类现在只能在 Winforms 项目中使用。
公开 ISynchronizeInvoke 类型的名为“SynchronizingObject”的属性。 GUI 层现在有选项要求您调用 ISynchronizeInvoke.BeginInvoke()。如果设置了属性，则执行此操作，否则直接触发事件。有几个 .NET Framework 类可以执行此操作，例如 Process、FileSystemWatcher、EventLog 等。但是，它与之前的解决方案存在相同的问题，该接口(interface)在非 Winforms 应用程序中不易使用。
要求客户端代码在 UI 线程上创建您的对象。并在构造函数中复制 SynchronizationContext.Current 。您可以稍后使用其 Post() 方法来调用。这是最兼容的选项，.NET 中的所有 GUI 类库都提供了此属性的值。
当您选择后一种项目符号时，请记住这一问题。客户端代码将从线程的代码执行中获取完全不同步的事件。具体的事件处理程序可能希望访问类的属性以了解有关类的状态的更多信息。该状态不太可能仍然有效，因为您的线程已经远远超过了 BeginInvoke() 调用。客户端代码根本没有选择插入锁来防止造成麻烦。如果这是一个真正的问题，您应该强烈考虑根本不提供帮助(通常情况下确实如此)。
关于c# - 通用 BeginInvoke 方案，确保在同一线程上下文中进行函数调用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24382735/