Multitasking Considerations

Systems Application Architecture CUA guidelines recommend that an application should complete the processing of a user- or system-initiated event within 0.1 seconds and be ready to continue interaction with the end user. The particular implementation of the message handling concept under Presentation Manager means that the application's primary thread must complete the processing of a Presentation Manager message before any further messages can be passed to applications; thus it is possible for the user to be "locked out" of the system if an application does not complete its processing within a reasonable period of time.

While the 0.1 second time period is adequate for the processing of most events, it may be insufficient for those that result in lengthy processing such as access to a remote system. It is therefore recommended that any window procedure performing some processing that is likely to take longer than 0.1 seconds to complete should carry out this processing using a separate thread of execution under OS/2. The application's primary thread may then initiate the secondary thread and immediately return control to Presentation Manager, thereby enabling the primary thread to continue with user interaction.

The separation of processing into a primary and one or more secondary threads may occur in a number of ways:

  • Where the window procedure is an object window procedure, and the majority of its methods may result in lengthy processing, the window procedure itself may be implemented in a secondary thread.

  • Where only a single method results in lengthy processing, or where the window procedure is concerned with a display object, a single subroutine containing that method may be started in a secondary thread.

    In certain circumstances where the different portions of an application's task are entirely self-contained, and where it is desirable to isolate the portions from one another, the application may be divided into separate processes. Division of the application in this way means that each portion resides and executes in its own address space, fully protected from other portions of the application. This approach is particularly useful for applications that exploit the Workplace Shell, since the implementation of the Workplace Shell in OS/2 Version 2.0 causes Workplace Shell objects to execute, by default, under the control of the Workplace Shell process. The use of multiple processes within an application provides better protection for resources used by Workplace Shell objects.

    Note that for performance reasons, the use of multiple threads within the same process is preferable to the use of multiple processes. This is because switching between threads involves far less system overhead than switching between processes.

    Processes and threads may communicate with one another in a number of ways for the purposes of exchanging information, and for synchronizing execution flow and access to data objects. The techniques of communication between threads and processes are described in Communicating With a Secondary Thread and Communicating With Another Process.

    Maintaining synchronization between threads and processes is discussed in Maintaining Synchronization.


    [Back: Summary]
    [Next: Creating a Secondary Thread]