C# 为什么用空委托调用ThreadStart？

在对一个旧应用程序进行法医考古调查时，我不得不坚持我遇到了以下问题：

这是一个最近转换为.NET4.0的WPF应用程序，该代码在后台工作程序中运行

           if(bgWorker1.IsBusy || bgWorker2.IsBusy)
           {
                Thread.Sleep(100); 
                Application.Current.Dispatcher.Invoke(
                    System.Windows.Threading.DispatcherPriority.Background, 
                    new System.Threading.ThreadStart(delegate { })
                );
           }

1-使用无操作委托调用线程（主gui）可能会产生什么副作用。另外两个线程也在主gui线程上执行调用，但只有这一个线程将优先级设置为非正常的（它们使用Action而不是TreadStart）

2-我有一些案例与此应用程序的死锁非常相似，有些情况告诉我这可能是原因。（无缘无故地搅乱优先级和主gui线程）

---

谢谢

此线程将导致调用函数阻塞，直到调度程序的线程可以“处理”该（无操作）委托为止

这可能不是一个好的做法，应该删除。我怀疑这里的目标是让这个（第三个）

BackgroundWorker

的完成事件成为前两个

BackgroundWorker

完成的信号

一般来说，像这样旋转来完成通常是一个糟糕设计的标志。一个更好的设计是使用，这可以由

BackgroundWorker

实例在完成时发出信号

然后，您可以只等待倒计时事件，而不是使用

Thread.Sleep

和dispatcher调用循环

“[…]可能会产生什么副作用”

因为它使用

Invoke

而不是

BeginInvoke

这将是一个阻塞调用。这意味着，在noop委托运行之前，后台线程不会继续执行。其效果是，在执行此noop之前，所有排队进入消息循环的内容都已执行之前，代码不会继续

“我遇到了一些与此应用程序死锁非常相似的情况，有些情况告诉我这可能是原因。”

听起来似乎很有道理。这段代码既有错误的做法，也有可能出现死锁。因为代码引用了其他后台工作人员，所以可能其他人也在做类似的事情

---

现在，似乎很明显有些地方出了问题，但如果不了解更多的情况，就很难对如何解决这个问题发表评论。我猜，在所采取的方法中存在一个基本的设计缺陷。

对我来说似乎毫无意义……调用可能会阻塞，直到主线程处理消息。因此，如果我理解正确，它基本上会在调度程序堆栈中设置一个排序书签，并在到达并处理书签之前停止线程。我猜这接近于面向副作用的编程的样子：-）。@Newtopian是的，有点像。它会一直阻塞，直到调度器运行委托（它什么也不做），所以是的，这确实是编程的副作用。谢谢，我并不是在寻找解决方案，但这段代码确实让我对它的用途感到困惑。谢谢帮助很大。