When you write a typical server to take advantage of threads, a
common design is to have a single listener thread waiting for client requests
and multiple individual worker threads to perform the client's requested operations.
Creating threads should not use very many resources. However,
because some servers require a faster response time to clients, some server
application programs maintain a pool of worker threads that are waiting for
work. They do this 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 request
and signals the waiting worker threads. The signal 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 it performs:
- You should 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 did. These rules concern the actions that it can take and 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 wanted for 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.