The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,229 other followers

Dear fellow programmer. If you aren’t experienced doing multi-threading, please don’t!

Posted by jpluimers on 2012/07/05

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.
       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

Someone built their own splash logic with multi-threading.

Funny that today, this got answered on StackOverflow by [WayBackmgie: [WayBack] multithreading – TMonitor synchronization / Application.ProcessMessages – Stack Overflow.

Though that is a Delphi link (and points to the nice libraries [] AsynCalls and [WayBack] OmniThreadLibrary), the most important link it contains is to  [WayBackBorland 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.

Recommended reading!

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.


6 Responses to “Dear fellow programmer. If you aren’t experienced doing multi-threading, please don’t!”

  1. You write “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.”

    How should anyone learn multi-threading if not by simply doing it? If they shouldn’t do it unless they are an expert, they can never become one. How did you start?

    • jpluimers said

      I don’t even feel to be an expert on multi-threading, so I build on what others do.

      What I have done in multi-threading myself were long painstaking processes with lots of test cases and lots of feedback, often from people on the same level as I was, but more so from people I have learned to know to do it in a better way than I am.

      In most cases, that feedback actually made me find solutions not involving multi-treading in the first place. For instance by improving the algorithms making the complete run-time process shorter.

      • EMB said

        I would change the text as following: “No matter what kind of programming environment: If you have not done lots of multi-threaded programming, then please, try not do it yourself: go ask someone that does know how to do it.”

        Cause as the way you wrote, seems that is better not to do it anyway. As if multi-threading was a sacred ground that only chosen-ones could step in.

  2. Rich Shealer said

    Good advice. There is a lot to understand about threading and I’ve only scratched the surface. Sometimes things just seem to be a little off especially around shutting things down. I really try to keep it simple and not get too clever.

    I usually use threads to monitor real time I/O and handle database operation for factory floor labeling applications. Everything else can wait a few hundred milliseconds.

    The OmniThreadLibrary made a lot things easier for me to work with even if I don’t understand everything Gabr talks about. He’s done a great job, I wish him a long healthy happy life.

  3. roland said

    Agreed. But in C# 5 things will get much easier with the await keyword.

    • jpluimers said

      Indeed, and the same in .NET 4 with the parallels framework and .NET with the BackgroundWorker. Those frameworks take away many of the gory details that you often get wrong when doing all of the treading stuff yourself. But even with frameworks, you have to know how to use it and what boundary conditions apply.

      I’ve seen many people doing even basic things wrong with the BackgroundWorker so for many of us doing things with threading is a steep learning curve even with good frameworks to start with.

      The next period for a lot of people will be to find a balance in a world where multi-core and multi-cpu is ubiquitous, processor frequency hardly increases and problems to solve get more and more complex.

      I’m really looking forward to that, as it is the base of the computer science I love: solving more and more complex systems with better and better technologies at hand.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: