Threads are important because they can exploit parallelism in certain types of applications. Different parts of the same application can run in parallel. Threads are particularly important in a distributed environment, and they are required for the implementation of the standard known as the Distributed Computing Environment (DCE). DCE uses the POSIX process model.

Because we wanted the AS/400 to implement both DCE and the POSIX interface, we had to find some way to support POSIX threads. We considered two models. The first was a native implementation of threads where we defined multiple TDEs per process. Each activation group could have its own TDE and, therefore, be a separately dispatchable unit of work. Each activation group in a process then would be analogous to a thread. This model also fits reasonably close to the threads model used in the industry. Unfortunately, this model also required more changes to OS/400 than time permitted for us to achieve an implementation for V3R1. So we had to select a second, somewhat less optimum, model for the initial implementation.

We defined the concept of a shared activation group for the second model of threads. Multiple OS/400 jobs can share the same activation group. Thus, a thread by this definition is an OS/400 job that shares an activation group. A POSIX process can be thought of as all OS/400 jobs sharing an activation group. All threads in the POSIX process share the same static storage and heap, while each thread has its own automatic (stack) storage.

This definition of using an OS/400 job as a thread works, but it has one big drawback: The full-function OS/400 job takes a long time to create compared to the lightweight thread other systems use. To improve AS/400 performance, we created a standby pool of previously created jobs. When a thread needs to be created quickly, one of the jobs from this pool is used. Destroying a thread moves the job back to the standby pool.

We introduced this thread model as part of our Common Programming APIs (CPA) toolkit at V3R1. This satisfied our initial objective, but we knew this measure was temporary. There were several other applications that we wanted to bring to the AS/400 — for example, Lotus Domino. We look at Domino and its relation to the AS/400 in Chapter 11, but for now we need to recognize that Domino is written to a thread model. To run Domino natively on the AS/400 requires an efficient thread implementation. We, therefore, began the work to develop a native-threads implementation for V4 of OS/400.

Figure 9.7 shows how the various application enablers relate to the two models of threads in the system. Application enablers here include the runtime libraries for languages such as C, C++, and Java; the integrated file system; and the class libraries for objects. In Chapter 11, we discuss Java and its object model as well as IBM’s System Object Model (SOM) and Distributed System Object Model (DSOM).

Figure 9.7  Application Enablers for Threads

Over time, we expect that more and more applications will be written to a threads model. Native threads allow these applications, which are often written for some other operating system, to efficiently run on the AS/400.

Conclusions

Various operating systems implement processes in different ways. Each system decides how the processes should be structured, how they are protected, and how robust they will be. The AS/400 process model has proven itself to be an industrial-strength implementation, capable of handling business-critical applications. The very modern tasking structure on which everything else is built allows this system’s process and job models to evolve to handle the needs of its future application environments.

In the following chapter, we look at the I/O system and how it is evolving to meet the AS/400’s future application environments. We will see how the tasking structure plays an important role in the I/O system, both now and in the future.