Skip to content
December 6, 2009 / lawrencebarsanti

Why I used threads

Threads are typically viewed as a very powerful but dangerous programming concept.  They are powerful concept because they allow code to be broken up into several executable chunks that can be scheduled by the operating system and run concurrently on multi-core/multi-processor systems.  Unfortunately, by doing this, your program become susceptible to a whole new breed of problems that are hard to reproduce and debug.  Because of this, I feel it is necessary (if only to prove to myself) to defend my usage of threads in a project that I am working on.

The Project

I work for a small company that makes custom ultrasonic equipment to monitor manufacturing processes and assess the quality of the manufactured goods.  On top of your normal CRUD application needs, this also involves communicating with manufacturing equipment, communication with ultrasonic hardware, and running complex signal processing algorithms in a time sensitive environment (order of ms) .  One of my main tasks is/was to combine all the pieces of this puzzle into a  monitoring application that can run on a dedicated Windows based computer that sits on the factory floor.

A typical manufacturing process will have a robot capable of making a few similar but different products.  It goes something like this:

  1. Robot sits idle waiting for materials to be loaded
  2. Materials for one of the products are loaded
  3. Robot is told to build the product
  4. Robot moves to a position
  5. Robot performs an action
  6. Repeats steps 4 and 5 until product is built

At this stage in our product’s development, the manufacturing environment is asynchronous meaning we have no control over its processes; things happen when they happen.  However, our ultrasonic equipment must collect data in real-time while actions are being performed (i.e. during step 5).  So if the software cannot activate the ultrasonic equipment at the right time, maybe it busy with a length signal processing algorithm, the data is lost forever.

My Approach

I separated the application’s functionality into two threads.  The acquisition thread has complete control of the hardware for collecting ultrasonic data and the hardware for communicating with the manufacturing equipment.  The main thread is responsible for everything else which includes user interaction, CRUD operations, and processing the ultrasonic data.  The acquisition thread sends the main thread messages using a thread-safe message queue.

Why it Works

The acquisition thread is assigned the highest priority possible when it is created and its main routine looks something like this.

while not Terminated do
  waitForStartActionSignal; // sleep
  acquireUltrasonicData;
  sendUltrasonicDataToMainThread;
end;

The acquisition thread spends the vast majority of its time waiting for signals from the manufacturing environment, so even though it has the highest priority possible, it does not starve the main thread or any other system processes for that matter.  However, as soon a signal is received from the manufacturing equipment, the acquisition thread instantly springs to life an runs uninterrupted until it next sleep.  Thus, the most important task, collecting ultrasonic data, will be completed on time no matter what the main thread or other system processes are doing.  Since, the acquisition thread sends information to the main thread through a queue, it can easily handle short periods of time where data is collected faster than it can be processed.

It has been a little over a year and a few hundred-thousand products since our first installation and I have to say that the approach described here has worked very well.  However, I am not immune to the problems that plague developers who try to harness the power of threads.  For the first month or so, the software would arbitrarily freeze and I could not figure out why.  Eventually, with a little help, I was able to find my one and only deadlock.

Advertisements

2 Comments

Leave a Comment
  1. W / Dec 31 2009 2:10 pm

    I also write apps like your apps, in Delphi. With the realtime/math/communication/controls elements.

    Hi.

    Warren

    • lawrencebarsanti / Dec 31 2009 3:37 pm

      Hi Warren.

      Do you blog about your work or programming in general? If so, post a link and I’ll check it out.

      Thanks for reading.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: