Worker Thread

Listing 5-3 shows our worker thread. The default implementation merely counts to 1,000, yielding every count. This is overly aggressive , but it does allow the system to remain highly responsive to other threads during execution. It's easy to imagine changing the behavior of this worker thread to do something more computationally complexfor example, when used in conjunction with the networking capabilities shown in Chapter 4, "Net" and this chapter, parallel execution could well be much faster and easier.

The implementation shown in Listing 5-3 drops out of the run() method when complete, rendering the thread no longer reusable. It would be possible to create a reusable WorkerThread instead of completing and dropping out of the run() method, the thread could instead have two statesa busy state and an idle state, with the thread returning itself to the pool when switching from the busy state to idle.

Listing 5-3. Worker Thread

package com.cascadetg.ch05;

import org.apache.commons.pool.ObjectPool;

public class WorkerThread extends Thread
{
    // The total amount of work done by the threads.
    static public long totalUnits = 0;
    // The number of times the thread should look over a counter
    // (this is our definition of work)
    private int counter = 1000;

    // When the thread is done, it returns itself to the pool.
    private ObjectPool hostPool = null;
    // Used to indicate that a thread, when completed, is no longer
    // useful.
    public boolean valid = true;

    public void setPool(ObjectPool myPool)
    {
        hostPool = myPool;
    }

    public void run()
    {
        // Loop over a counter, and yield each time to allow other
        // threads to execute.  In a "real" app, you wouldn't need
        // to yield anywhere near this often.
        for (int i = 0; i < counter; i++)
        {
            totalUnits++;
            yield();
        }
        try
        {
            // We synchronize on the pool to avoid possible
            // threading problems, and return our object.
            synchronized (hostPool)
            {
                this.valid = false;
                hostPool.returnObject(this);
            }
        } catch (Exception e)
        { e.printStackTrace(); }
    }
}

Finally, Listing 5-4 shows an example of the output of this application. Paying close attention to the output, we can see that in this particular case, a non-parallel approach has the best timing. This is to be expected in a CPU- dependent, single system environment, but in environments involving potentially slow resources (such as network access), the results may be quite different.

Listing 5-4. Sample Output

Starting 30/30
Total created threads:30
Seconds Elapsed: 0.191
Completed:            30000
units/second:       157068.06

Starting 100/100
Total created threads:100
Seconds Elapsed: 0.801
Completed:            100000
units/second:       124843.945

Starting 1000/1000
Total created threads:1000
Seconds Elapsed: 9.794
Completed:            1000000
units/second:       102103.33

Starting 1000/2000
Total created threads:2000
Seconds Elapsed: 19.127
Completed:            2000000
units/second:       104564.23

Starting 1/3000
Total created threads:3000
Seconds Elapsed: 5.398
Completed:            3000000
units/second:       555761.44

Starting 10/3000
Total created threads:3000
Seconds Elapsed: 6.85
Completed:            3000000
units/second:       437956.22

Starting 30/3000
Total created threads:3000
Seconds Elapsed: 7.641
Completed:            3000000
units/second:       392618.78

Starting 1000/3000
Total created threads:3000
Seconds Elapsed: 28.471
Completed:            3000000
units/second:       105370.375

Most efficient @ 555761.44
(1/3000)
Done.