Summary
I've noticed that, in descriptions of threading, the levels of abstraction are often mixed, which I believe adds to the confusion already present in understanding threading. In this short exerpt from "Thinking in Java fourth edition," I attempt to clarify the situation.

(Exerpt from "Thinking in Java fourth edition")

As the previous section shows, you have choices in how you implement concurrent programs in Java, and these choices can be confusing. Often the problem comes from the terminology that’s used when describing concurrent program technology, especially where threads are involved.

You should see by now that there’s a distinction between the code that’s being executed and the thread that drives it; this distinction is especially clear in the Java libraries because you don’t really have any control over the Thread class (and this separation is even clearer with executors, which take care of the creation and management of threads for you). You create tasks and somehow attach a thread to your task so that the thread will drive that task.

In Java, the Thread class by itself does nothing. It drives the task that it’s given. Yet threading literature invariably uses language like “the thread performs this or that action.” The impression that you get is that the thread is the task, and when I first encountered Java threads this impression was so strong that I saw a clear “is-a” relationship, which said to me that I should obviously inherit a task from a Thread. Add to this the poor choice of name for the Runnable interface, which I think would have been much better named “Task.” If the interface is clearly nothing more than a generic encapsulation of its methods, then the “it-does-this-thing-able” naming approach is appropriate, but if it intends to express a higher concept, like Task, then that name is more helpful.

The problem is that the levels of abstraction are mixed together. Conceptually, we want to create a task that runs independently of other tasks, so we ought to be able to define a task, and then say “go,” and not worry about details. But physically, threads can be expensive to create, so you must conserve and manage them. Thus it makes sense from an implementation standpoint to separate tasks from threads. In addition, Java threading is based on the low-level pthreads approach which comes from C, where you are immersed in, and must thoroughly understand, the nuts and bolts of everything that’s going on. Some of this low-level nature has trickled through into the Java implementation, so to stay at a higher level of abstraction, you must use discipline when writing code (I will try to demonstrate that discipline in this chapter).

I shall try to clarify these discussions by attempting to use the term “task” when I am describing the work that is being done, and “thread” only when I am referring to the specific mechanism that’s driving the task. Thus, if you are discussing a system at a conceptual level you could just use the term “task” without mentioning the driving mechanism at all.

Talk Back!

Have an opinion? Readers have already posted 23 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.