Domanda

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?

È stato utile?

Soluzione

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.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top