A/D Trends: POSIX Threads on the AS/400

• 10/19/1998

The AS/400 now supports multi-threaded applications with the release of OS/400 V4R2. This function of V4R2 allows you to port your old CPA thread applications and NT thread applications to an AS/400 kernel thread application. It also enables you to create new multi-threaded applications for the AS/400. But why would you want to? Let’s look at the basics behind threads and the pros and cons of using this programming style.

A thread is a single unit of execution in a program. The amount of system resources used for a thread is far less than those used for a job. But, the resources needed to start a multi-thread application are greater than for a single-threaded application.

A process is the container for all of the threads within a multi-threaded application. Each of these threads runs simultaneously, while sharing the same memory and job resources. The first thread called is known as the initial or main thread.

The AS/400 supports the POSIX (portable operating system interface) threads-approved standard, with some exceptions. This standard describes a set of threading APIs and how they function and interact with the operating system. The AS/400 has supported POSIX threads since V4R2, but has restricted access to the library. Full access to the thread library will be available in the release of V4R3.

The primary advantage of using a multi-threaded process is that it allows a job to accomplish more at the same time. It will also reuse the same resources if they are available, knowing that it has used the same resources before. Since the threads are sharing and reusing the same resources, it allows for quicker processing and more efficient resource management.

A key benefit of implementing a multi-threaded application is the rapid response time. After the initial thread has been created, the following threads use the same resources. This will result in a performance gain because the resources do not have to be allocated to the new thread. Since it does not have to allocate resources to all of the threads, the server will have more available resources for other jobs.

Client connections can be better managed using POSIX threads. A simple counter can be put in place to maintain a static level of user connections. This can result in faster processing, because there are a smaller number of clients using a specific process. Logging can also be implemented within the process to keep track of all of the current clients. If you wish to end a specific process, all you have to do is end the job. In the end, all related processes and messages can be sent to all current clients.

Currently, there are two ways to start a multi-threaded job on the AS/400. You can either use a pre-start job, or a job started using the spawn function from the thread APIs. Any other attempt to start a multi-threaded application will result in an error. This controls the start of multi-threaded jobs on the AS/400, and allows for a tighter security on when it is going to be used.

In the current release of thread support, each thread uses the same user profile as the job. This may cause a problem if you wish to have the profile of the current user rather than the job. But if you wish all users to have the same security and authorities, this does not pose a problem. The ability to change the security level of each thread will be available on the next release of the operating system.

Why not just speed up processors and save all the programming work in order to get the job done faster? Sure, and we know that "Moore’s Law" steadily advances the price performance of microprocessors. But today’s complex software applications handle enormous complexities, interrelationships, transactions and computational work. They require far more processing power than can be created by a single processor. Thus we see all hardware vendors resort to "Symmetrical Multi Processing" – the use of multiple processors instead of a single one – to boost performance.

While the AS/400 has had this function for years, recent announcements show colossal performance capabilities on new 12-way A50-based AS/400s (Model S40, 650). To truly reap these benefits when coding large, complex applications, programmers need to embrace threading capabilities. It’s a way of doing more with, well, more.