This article explains the unsuitability (from a design point of view) of using thread libraries for implementing multithreaded systems. Please do provide me with your comments and suggestions to improve this article - areas that need further clarification, errors/omissions.
1 INTRODUCTION
Abstraction and encapsulation are key to managing complexity. Objects provide good abstraction by, among other things, modeling reality. However, a crucial part of reality that is not represented adequately in an object is a sense of time. Objects exist in time and space, and interact with other objects to do things; they have "life".
Spatial representation, OK.
Temporal representation, not OK.
A mechanism for intuitively expressing the idea of a Live Object* (or Active Object), is inadequately supported by the threading libraries of object-oriented languages today. Threading libraries hide very little of the complexity involved in the use of threads.
Many, if not most, non-trivial applications are multithreaded. Often, the focus and the major obstacles in implementing a multithreaded system are the low-level details of threading, rather than the problems that the system is designed to solve.
*Live Object makes for a better acronym (LOOP) than Active Object (AOOP??). It can also be interpreted as the imperative "Live! Object." :-)
2 CURRENT THREADING MECHANISMS
Presently to use threads, we create a thread and give it sections of code (from the object possibly) for it to do. For example,
threadHandle=CreateThread(StuffToDo , OS/LibraryParameters)
is how threads of control are created from a program. The code (StuffToDo) is then executed in the newly created thread.
In the present library implementations,
2.1 Threads use objects.
Threads use the code from objects to be more precise. The thread executes the function that we specify. In the example, StuffToDo could be the method of an object.
2.2 Threads are to functions what objects are to classes.
Or, threads are objects. The thread object instantiates a function, brings into execution-space so to say, executing it. The library makes the thread a first-class "object" in the program-space. It has a handle, threadHandle, that can be used to refer to it.
2.3 Threads are almost equivalent to operating system threads.
Most of what can be done with an operating system thread can be done with library threads also - one can suspend a thread, resume it, abort it etc.
3 'OBJECT'IONS - CRITIQUE
3.1 Unnatural modeling
In the real world, entities use their time and their resources to do things. Abstractly, a thread can be viewed as a flow of time. In the library-model, threads use objects (Refer 2.1) whereas in the real-world, objects use threads. This inappropriate modeling contributes to the difficulties of conceptualizing and implementing threaded systems.
It should be
"Objects use threads",
not "Threads use objects".
3.2 Dubious Relevance of Thread Objects In Program-Space
An object oriented program/system is an exchange of messages between objects resulting in side-effects useful towards the solution of the problem at hand. Thread objects (Refer 2.2) are, in their current avatars, only a way of calling a function; they do not help to manage complexity. Instead, thread object interactions intrude on the main logic of the program.
Hide the complexity of threads
from the programmer, effectively.
3.3 Abstraction Leakage
Why have thread objects at all in programs? Threads are very much operating system entities (Refer 2.3), but are they really required at the abstraction level of the program? If we have thread objects in the program, it is only natural that they have methods and behaviours similar to the real-world (albeit on the OS-side) entities that they model, with some high-level constructs thrown in for good measure. If we have thread objects, the programmer will necessarily be exposed to their complexity as well. So much for abstraction and encapsulation!
For operating systems, threads are expensive to manage. The objection to live objects that is raised all too often is: "What! If I have a 1000 live objects, it would mean 1000 threads too? You must be out of your mind..." . This mental block must be removed. The programming language back-end, the popular idiom of the runtime, could possibly be adapted to meet the external implementation constraints/limits.
Eliminate threads from
the programmer's vocabulary.
4 CONCLUSION
The language should help people to take their minds off low-level threading details and focus on more domain-relevant issues at hand, enabling the construction of more useful programs.
- Thomas Jay Cubb
http://oozone.blogspot.com/
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin