Multithreaded server recommendations
When you write a typical server program to take advantage of threads, a common design is to have a single listener thread wait for client requests and to have multiple individual worker threads perform the operations requested by the clients.
Creating threads should not use many resources. However, because some servers require a faster response time to clients, some server application programs maintain a pool of worker threads that wait for work to avoid creating new threads.
Typically, the worker threads use some synchronization primitive to wait for client processing requests. Instead of creating a new thread to process each client request, the listener thread queues the client requests and signals the waiting worker threads. The signal action sometimes uses variables.
A server application is commonly considered trusted with the data that it serves to clients. Because the server is running multithreaded applications, you must consider some issues concerning the activities that the server performs:
- You must not call user application code from a multithreaded server. To run user application code safely from a multithreaded server, the user application code must follow the same strict rules that the original multithreaded server uses. These rules concern the actions that it can take and concern the application programming interfaces (APIs) that it can call.
- As you should with any other part of your application, you must evaluate the processing that is required to fulfill the client request for its thread safety.
- Processing on behalf of the client might affect process-level resources of the server in a way that is not desired by the server. For example, changing the coded character set identifier (CCSID) so that data representation is the same as that of the client also affects other threads in the job. CCSID is a job resource.
- A server can change the security information (user profile and group profile) of a worker thread to make it become the client that is being served. However, when the server does this, you need to consider what resources the threads share. The worker thread has access to all the already opened job level resources that more privileged users in the same job might have created or opened.