KER,THREAD arf 1 - Thread definition

[Francois-Rene Rideau]

>> A thread is a part of a task that can _act_ as a separate task in the meaning
>> of program execution, but is a method in a program and shares the program
>> data and code-space.

 There's no fundamental difference (from the system's point) between tasks and
threads; there are larger or smaller threads; threads sharing more or less
(real, virtual, virtual virtual, virtual^n) memory (=objects) with other
threads, where the other thread can be part of a device manager, or a server
(for example, if we are to build a GUI "server" as X-Window for Unix, we'd
like not TO HAVE to pipe all data thru a PHYSICAL file; rather share virtual
window objects, for the system to maintain if the server is remote, or to
be actual shared memory if the server is at hand. Whatever, I don't like
the X server structure at all: you have low-level access to high-level
structure, etc).

 So we have a thread/task/running-code class; a program/procedure is a
function returning running code, (parameters being global data zone, for
example). The code actually runs if it is linked to the running list in the
task manager; else it is interrupted.

>> Meaning of program execution means that it has got its own entry in the task-
>> list.
(That's it)

The task specific concept is available only if hardware support special
task managing as with the i386 cpu. But this has to do with implementation,
and not with moose specifications.

>> The thread must contain abilities to lock and unlock data, and the code that
>> initializes the thread should be able to do so before the thread start its own
>> execution.
As a function returning running code, a program class method can itself include
computations, that is running code ! So loader/ender routines are no problem.

   ,
Fare