自定义跟踪侦听器冻结 WPF 应用程序中的 GUI
完全重写了这个问题，因为我现在有了更多关于正在发生的事情的信息。
我有一个自定义跟踪侦听器，它重写 writeline 方法以将字符串添加到自定义可观察集合中。此集合类将所有通知事件分派到 UI 线程，以允许其他线程更新它，并且仍然允许 WPF 数据绑定。
我有一个包含列表框的用户控件。列表框将跟踪侦听器中的可观察集合绑定到其项目源。
在我的应用程序启动中，我设置了窗口/用户控件/视图模型，并显示窗口。然后，我启动一个工作线程，该线程运行应用程序所需的一些后端进程。如果后台线程在 UI 线程完成所有用户控件设置和数据绑定之前执行 Trace.WriteLine，我的应用程序就会死锁。
通过在 UI 线程中添加睡眠和其他随机长时间运行的任务和/或延迟启动工作线程以使 UI 线程有时间完成，我已经能够在某种程度上合理地证明这种竞争条件。
我现在考虑实现的解决方案是创建一个 AppSetupCompleted 方法，该方法启动所有后端进程的工作线程，并将其发送到具有后台优先级的调度程序。从理论上讲，这是否应该延迟工作线程，直到 WPF 控件和视图模型的所有绑定都已成功设置？
Completely rewrote the question as I now have more information about what is happening.
I have a customtracelistener which overrides the writeline method to add strings to a custom observablecollection. This collection class dispatches all notification events to the UI thread to allow other threads to update it, and still allow WPF data binding.
I have a usercontrol which includes a listbox. The listbox binds the observablecollection in the trace listener to it's itemssource.
In my application startup, I set up the windows/usercontrols/viewmodels, and show the window. I then kick off a worker thread that runs some backend processes required for the app. If the background threads do a Trace.WriteLine before the UI thread has completed all the user control setup and databinding, my application deadlocks.
I've been able to somewhat reasonably prove this race condition by adding sleeps and other random long running tasks in the UI thread and/or delaying starting the worker thread to give the UI thread time to complete.
The solution I'm thinking of implementing now is creating a AppSetupCompleted method which kicks off the worker threads for all the backend processes, and sending this to the Dispatcher with a Background priority. In theory, should this delay the worker threads until all of the bindings for the WPF controls and viewmodels have been setup successfully?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对我来说听起来像是死锁或活锁...假设死锁（应用程序冻结时 CPU 较低），将调试器附加到应用程序并打破它。查看线程的调用堆栈（UI 和您从中调用 Trace.WriteLine 的线程）以查看它们锁定的位置。
如果您无法弄清楚这是阻塞的，请将调用堆栈添加到您的问题中，这可能会帮助我们回答您的问题。
sounds like a deadlock or livelock to me... assuming deadlock (low cpu when app freezes), attach a debugger to the application and break it. Look at the call stack of the threads (UI and the one you called Trace.WriteLine from) to see where they are locking.
If you can't figure out that is blocking, add the call stacks to your question, it may help us answer your question.