CPU or I-stream affinity
A program restricted to run on a particular I-stream engine is said to have a CPU affinity. A program with a CPU affinity has no need to call locks associated with critical regions if the data modified by the program is not shared by programs running on other I-stream engines. So, a program is given a CPU affinity if it accesses particular main storage tables that are not accessed by any other programs; this eliminates the overhead of locking. Note, however, that only one copy of the program can run at any one time in the I-stream engine. Moreover, it is not appropriate to assign a CPU affinity if there are several programs that access a single main storage table. Of course, CPU affinity does not restrict a program from using locks to access data that is shared. But, incorporating a lock into an existing program represents a modification. A program designed to be serially reusable in a uniprocessor environment operates satisfactorily without modification in a tightly coupled multiprocessor environment if the program is restricted to run on a single I-stream engine, and if none of the data that it modifies is shared with programs running on other I-stream engines.
Examples of some z/TPF system functions that must run with a CPU affinity are non-module-related I/O interrupt processing, timer service, and command processing. Commands are called operator messages or commands in other operating systems.
- Locks are avoided on highly accessed tables.
- Programs designed for a uniprocessor environment can be used with minimal modification.
- Additional procedures must be created to move requests from other I-stream engines and to notify other I-stream engines about the results of a program that runs with a CPU affinity.
- Restricting a program to run on a single I-stream engine can cause queuing problems that degrade performance.