Preserving Data Integrity

Since data resources are owned by a process, rather than by threads within the process, multiple threads may have addressability to the same static data storage areas, and potential problems arise with regard to serialization of data access and maintenance of data integrity. Similarly when multiple processes have access to a shared memory object, it is the responsibility of the application to ensure the integrity of shared resources; neither OS/2 nor Presentation Manager provide any automatic methods of avoiding such problems. However, mechanisms are provided whereby the application developer may prevent problems from occurring. Some suggested techniques for private data are as follows:

  • For any data that is private to a thread, use local variables defined within the thread, or automatic storage assigned from the stack (because each thread has its own stack memory object, this data is automatically protected since no other thread has addressability to this area of memory).

  • For any data that is private a particular window (as distinct from the window class), create a memory object to store this data and place a pointer in the window words, as described in Instance Data and Window Words.

  • Specific data areas may be used to contain data that is passed between threads or processes. If this data is only accessed in response to particular messages passed between the threads or processes, and if these messages are only generated at predefined points in the application's execution (such as on entry to and exit from a window procedure), it is relatively simple for an application to control access to these data areas.

    Static allocation of such data areas is permissible where the accessing routines reside and execute solely under the control of a single application. However, where such routines are placed in a library and accessed by multiple applications, the potential for data corruption through application error increases significantly, and dynamic data allocation prior to invoking a secondary thread or passing a request to another process should be considered to ensure the integrity of data areas.

  • For any code that will be placed in a DLL, it is important that a separate set of memory objects is created for the data of each process that will access the DLL. In order to ensure this, a DATA NONSHARED statement should be specified in the module definition file (see Module Definition File).

    Note that the above techniques apply to data shared between threads within a process; OS/2 provides a variety of mechanisms for dealing with data and memory areas that are shared between processes. These techniques are described in the IBM OS/2 Version 2.0 Control Program Reference.

    [Back: DosWaitChild() Function]
    [Next: Client-Server Applications]