Thread-specific data

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahw%2Frzahwe21rx.htm

Typical applications that are not threaded use global storage. When changing the application or application services to run in a multithreaded application, you must use a synchronization technique to protect global storage from being changed by multiple threads at the same time. Thread-specific data allows a thread to maintain its own global storage that is hidden from the other threads.

Due to the design of the application, threads may not function correctly if they share the global storage of the application. If eliminating the global storage is not feasible, you should consider using thread-specific data.

Consider the example of a server that stores information about the client and the current transaction in global storage. This server would never be able to share the client information in a multithreaded environment without significant redesign. The application could instead pass the client information from function to function instead of using the global client information.

However, the application could maintain the client and transaction information in thread-specific data more easily than it could be modified to eliminate the use of global storage. When each new thread is created, the thread would use a global identifier (or key) to create and store its thread-specific data. Each client (thread) would then have unique but global client data.

In addition, some application programming interface (API) sets provide a way for the system to automatically call a data destructor function that cleans up the thread-specific data when a thread ends.

Use the following as examples for your program:

• Example: Thread-specific data in Pthread programs
• Example: Thread-specific data in Java programs