Introduction - Java Concurrency in Practice - page 4

1.2.2. Simplicity of Modeling
It is often easier to manage your time when you have only one type of task to perform (fix
these twelve bugs) than when you have several (fix the bugs, interview replacement candid-
ates for the system administrator, complete your team's performance evaluations, and create
the slides for your presentation next week). When you have only one type of task to do, you
can start at the top of the pile and keep working until the pile is exhausted (or you are); you
don't have to spend any mental energy figuring out what to work on next. On the other hand,
managing multiple priorities and deadlines and switching from task to task usually carries
some overhead.
The same is true for software: a program that processes one type of task sequentially is sim-
pler to write, less error-prone, and easier to test than one managing multiple different types
of tasks at once. Assigning a thread to each type of task or to each element in a simulation
affords the illusion of sequentiality and insulates domain logic from the details of scheduling,
interleaved operations, asynchronous I/O, and resource waits. A complicated, asynchronous
workflow can be decomposed into a number of simpler, synchronous workflows each run-
ning in a separate thread, interacting only with each other at specific synchronization points.
This benefit is often exploited by frameworks such as servlets or RMI (Remote Method In-
vocation). The framework handles the details of request management, thread creation, and
load balancing, dispatching portions of the request handling to the appropriate application
component at the appropriate point in the work-flow. Servlet writers do not need to worry
about how many other requests are being processed at the same time or whether the socket
input and output streams block; when a servlet's service method is called in response to
a web request, it can process the request synchronously as if it were a single-threaded pro-
gram. This can simplify component development and reduce the learning curve for using
such frameworks.
1.2.3. Simplified Handling of Asynchronous Events
A server application that accepts socket connections from multiple remote clients may be
easier to develop when each connection is allocated its own thread and allowed to use syn-
chronous I/O.
If an application goes to read from a socket when no data is available, read blocks until
some data is available. In a single-threaded application, this means that not only does pro-
cessing the corresponding request stall, but processing of all requests stalls while the single
thread is blocked. To avoid this problem, singlethreaded server applications are forced to