OS/2 allows multiple threads of execution to be initiated within an application. Each thread is regarded as a distinct unit by the operating system, and is scheduled independently of other threads and processes in the system. Each application has a primary thread, created when the application is started. An application may optionally create one or more additional threads, known as secondary threads.
In certain circumstances, an application may also create additional processes to perform some portion of the application's processing. The use of additional processes may be necessary where different portions of the application's processing must be isolated from one another. It is also useful for applications that exploit the Workplace Shell since by default, all Workplace Shell objects share the same process and are hence unprotected from one another. The use of multiple processes has performance implications due to additional system overhead and should thus be implemented with care.
Secondary threads and processes may contain object windows, which do not appear on the display screen but act as addresses to which messages may be sent in order to initiate application processing. An object window typically "owns" a data object such as a database or controls access to an external entity such as a remote system. Where the processing in response to an application event requires access to another data object, the use of object windows in a secondary thread is recommended.
Communication with an object window is performed in the normal way using Presentation Manager messages. With suitable programming conventions, the handle of the object window may easily be made available to the calling window in order for such messages to be posted.
A single object window may receive messages from multiple windows, and perform actions on its data object on behalf of those windows. This approach allows easy coordination of requests for access to a data object, enhancing data integrity and efficiency of access. Applications that use this technique follow the basic client-server architecture, within the boundaries of the Presentation Manager application model.
Where the scope of a long-running event is restricted to a single method within the current application object, a secondary thread or process may be initiated without an object window. In such cases, a subroutine is initiated in the secondary thread, and the thread terminates immediately upon exiting that subroutine.
Presentation Manager provides a number of methods by which an application can synchronize access to data objects and determine whether a secondary thread or process has completed processing an event. These methods involve the use of functions such as DosWaitThread() or DosWaitChild(), Presentation Manager messages and/or event semaphores.
The multitasking capabilities of OS/2 allow greater application responsiveness since lengthy application processing may be performed in an asynchronous manner, leaving the application's primary thread free to continue interaction with the end user. This also facilitates conformance with the Systems Application Architecture CUA guideline stipulating that an application should complete the processing of an event and be ready to handle further user input within 0.1 seconds.