Good thoughts. Very.
The most common mis-use of threads that I see is the “flaming arrows strategy.” For each request, light another flaming arrow (a thread), and shoot it into the air to land where and how it may and then die. This is sure to overwhelm almost any scheduler, which also has no real way to distinguish one scheduler-unit-of-work from another. It also burdens the system with setup and teardown of processes, which is often expensive.
A far better (and, far more scalable) approach is to do what’s done in, say, any restaurant: to have a pool of workers who shift their attentions among a greater number of active orders, which are flowing station-by-station through a flexible and well-defined lifespan. The workers can be generalists, or specialists, or sometimes both, and the allocation can be adjusted at any time. The system that is built using threads/processes, is very aware of exactly what business-problem it is constructed to solve. When a unit of work is obliged to wait, a worker is not. Instead, the order is briefly “parked.” Workers live to a ripe old age. If a single work-unit needs to go to several stations at once (burger, fries, milkshake), it might be opportunistically serviced by three workers simultaneously. Commitments regarding service level are engineered into the system, so that you can say (and measure), that “95% of the time, all orders will be prepared and served to the customer within 3 minutes.” Concurrency is used to address the problem, but there is not a one-to-one correspondence between workers and work. There is a dedicated management role, separate from any worker, which is constantly “riding the faders” to keep everything in balance.
There are plenty of good workload-management systems, including some that are designed to share work in a computing cluster, as well as those that are designed to be self-adapting to changing workload mixes and resource-constraint pressures. The goal is to find the ever-changing “sweet spot” in which a maximum number of units-of-work are being processed, in the least amount of time, without creating traffic-jams at any point (including the OS scheduler itself). The principles used are simply taken from the real world of human and industrial processes.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.