Recently I was asked to investigate a performance problem with a certain .NET application.
The first error I got when getting the app to build in Visual Studio 2010, and then run it was like this:
System.ComponentModel.InvalidAsynchronousStateException was caught Message=An error occurred invoking the method. The destination thread no longer exists. Source=System.Windows.Forms StackTrace: at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle) at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object args, Boolean synchronous) at System.Windows.Forms.Control.Invoke(Delegate method, Object args) at UI.Splash.SetStatus(String status) in C:\...\Splash.cs:line 395 at UI.Menu.Main() in C:\...\Menu.cs:line 4275 InnerException:
Someone built their own splash logic with multi-threading.
Funny that today, this got answered on StackOverflow by mgie: multithreading – TMonitor synchronization / Application.ProcessMessages – Stack Overflow.
Though that is a Delphi link (and points to the nice libraries AsynCalls and OmniThreadLibrary), the most important link it contains is to Borland Newsgroup Archive :: borland.public.delphi.internet.winsock :: Re: Disconnect TIdHttp in thread.
That sounds like a Delphi link too, but the subtitle “‘Ways to get into avoidable trouble with threads, V1.2′” hints the essence: it is a post that describes in an environment-agnostic way how to avoid multi-threading problems.
Anyway: Building multi-threaded code is hard. Even harder fleshing out all the corner cases and potential error conditions.
No matter what kind of programming environment: If you have not done lots of multi-threaded programming, then please don’t do it yourself: go ask someone that does know how to do it. Or better, try to avoid it.
I try to let libraries to the handling of multi-threading for me, if I use multi-threading at all, as others are far better at this than I am.