Re: question about tasks, multithreading and multi-cpu machines

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

Actually, I think the Ada task concept very closely match the way the
term task is used in programs for project planning and organizers.  An
Ada task definition really says what needs to be done, it does not
consider the mapping to OS processes or threads, only the steps to get
the job done, and the interfaces to other tasks. A task may not
terminate before its sub-tasks terminate. Much like the planning stage
of a project, I would say. Luckily, you do not have to hunt for
resources or map tasks to threads or processes, the compiler and run
time system does it for you. Also observe that the specification of
protected types is such that it is possible to run code which is
realted to two different tasks in the same thread. So I would say that
really, Ada tasks *are* logical tasks, not threads or processes. If you
think about Ada tasks as communicating sequential (logical) processes,
it is perhaps easier to see what I mean.

If you would like more interesting food for thought, have a look at the
Occam language. You have to explicitly tell the compiler if you want
things to be done sequentially, otherwise it is free to run your
statements in parallel :-)

>>>>> "MS" == Maciej Sobczak <no.spam@no.spam.com> writes:

    MS> Jeffrey Creem wrote:
    >> Actually, threads  is misleading since threads are  just tasks minus
    >> rendevous. It  all just depends  on your perspective. Since  Ada had
    >> tasking before  (most) unix  had threads I  think Unix got  the name
    >> wrong :)


    MS> In my humble opinion, Ada got it wrong in the first place.

    MS> {Pre-flame note: below  is a very informal description  of how I think
    MS> about these  terms while designing/programming/etc., not  how they are
    MS> defined in any language/system/etc. standard.}


    MS> What's  funny, the  terminology  is correctly  used  in even  simplest
    MS> programs for project planning, organizers, and such.


    MS> The "task" is something that needs to be done. It's an objective, or a
    MS> goal  to  achieve.  (I'm  not   an  English  native  speaker,  but  my
    MS> dictionaries seem to confirm this.)


    MS> To  actually  perform any  given  work,  some  kind of  "resource"  is
    MS> needed. Whether  it is a human  resource or a  computing resource does
    MS> not matter -

    MS> what's important is that this "resource" is treated as an *ability* to
    MS> perform work. What's even more important is that there might be unused
    MS> resources lying around, which can be just used to perform some work if
    MS> they are available.


    MS> Now, "thread"  is a software  resource that represents the  ability of
    MS> the system to do some work.


    MS> The difference between "task" and "thread" is that "task" is something
    MS> to do, whereas "thread" is a way to do it.


    MS> The tasks in  Ada do not match any of the  above. Other languages (for
    MS> example Java)  also got  it wrong, by  treating threads as  objects or
    MS> even by allowing  a programmer to "subclass" or  "specialize" a thread
    MS> class. None  of the  languages that  I'm aware of  allows me  to treat
    MS> tasks and threads  as they really are, which  means that everybody got
    MS> it wrong in one way or another. :)


    >> So, the only  thing I am trying  to say here is that  people seem to
    >> assume  that task, thread  and process  have some  formal definition
    >> that is all powerful. This is not true.


    MS> Right.

    MS> -- 
    MS> Maciej Sobczak : http://www.msobczak.com/
    MS> Programming    : http://www.msobczak.com/prog/

-- 
   C++: The power, elegance and simplicity of a hand grenade.