Introduction to multi-threaded programming -- part 1

Ron Turull

Multi-threaded programming was introduced on the AS/400-iSeries back in V4R2, but was limited to C and Java programs. Multithreaded programming took a big step up with the release of V4R4 when multithreaded support was added to the RPG and COBOL languages. But multithreaded programming on the iSeries is still a work in progress.

What is multithreaded programming?

A thread – short for thread of control -- is a path of execution that a program takes. All the programs you have created in the past on the AS/400-iSeries have been "single-threaded" applications. That is, your programs have followed a single path only of execution at any given time. True, the path may vary depending on conditions and control structures at the time of execution, but there is one path only of execution at any given time. For example, when you see a program trace, you see just a single column of instructions -- a single path of execution, a single thread -- not multiple columns of instructions.

Multi-threading is the ability of a program to spawn additional, simultaneously-executing paths of execution. Put another way, it is the ability to have multiple "parts" of a program executing at the same time. Think of it as a client-server application with both the client part and the server part in the same program. In fact, that is one of the best applications for multi-threaded programming.

Advantages of multithreaded programming

The main advantage of multithreaded programming is the ability to spawn off some code to run in the "background" while the rest of the program does something else. For example, consider the typical order-entry program described in the following flowchart. It shows a single path of execution.

Now consider the next flowchart. It is the same application, but this time it is split into two paths of execution that will execute simultaneously. The first path is called the primary thread. It allows the user to enter the customer's order. When the order is complete, it spawns off a secondary thread that will run in the "background" to update the inventory files, process backorders for any items that are out of stock, and write the order to the order-entry files.

Meanwhile, the primary thread allows the user to immediately enter the customer's payment information (e.g., credit card number, COD, terms, etc.). When that is complete, the primary thread joins with the secondary thread; that is, it waits for the secondary thread to end, which will probably already be finished in this case.

This is advantageous because it allows the user to work uninterruptedly, instead of waiting while the program is processing something else. We'll take a look at the mechanics of multithreaded programming next time.

About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.

This was first published in November 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.