From:  Roger Racine <[log in to unmask]>

> Terminology seems to be a big problem with people learning Ada.  The Ada
> language uses different terminology than others (aka C, C++, Java).  The
> latest example is with "tag type" vs "class", but a much older difference
> is with Ada's use of the word "task" vs "thread" in C.

Is it truly a big problem?  If language A uses a different term for
what is really the very same concept in language B, don't people get
over it pretty quickly?  That's the kind of difference that is really
easy to learn.  "OK, I get it... what they call a 'foo' over here is
just their word for what I knew over there as a 'goo'; they're exactly
the same... got it."  For instance, I've never heard of anyone trying to
learn Java and getting hung up over the fact that Java uses the word
"method" to refer to what C++ calls a "member function".  By the same
token, I have a hard time imagining that the use of the term "task"
instead of "thread" presents any serious obstacle to learning Ada...?

> ...
> I have seen some discussions about Ada tasks vs POSIX threads, and was
> surprised to see someone suggesting that they are not synonymous.

Wow... I'd be suprised if I heard someone suggest that they _are_
synonomous.  Since they really are not at all synonomous, if I had to
take sides I would have to say that ideally the Ada thing should be
named anything _but_ "thread", to avoid confusion.

But then I thought about how when I encountered the Thread class in
Java, I did not experience any tendency to confuse it with POSIX
threads.  (I also don't believe that the name "Thread" -- as opposed to
"task", and certainly not by way of analogy to Posix threads -- helped
me at all in learning about them).  This led me to believe that it
really doesn't matter very much.  I had been ready to go into all the
arguments for why it's such a good thing that the Ada term is different
(since they are in fact different things), but I now think that Ada is
probably neither helped nor hurt by this "difference".

It's also possible that because of my knowledge of Ada tasks vs. POSIX
threads, I've been conditioned not to assume that a language-intrinsic
tasking construct is "the same as" some OS threads capability; in other
words, when I saw "class Thread" in Java, instead of thinking "ah,
'thread', like in C/Posix -- this must have to do with concurrency", I
thought "OK, this is probably kind of like an Ada task."  So allowing
for that possibility, I'd still have to lean a little toward the
"different terms is good" side.

> The
> argument went something like this: Since tasks are built in to the
> language, the compiler knows about them.  Since the compiler knows about
> them, there are times that the compiler can optimize them such that a new
> thread is not needed.  Therefore there is a difference in terminology.

I think it's more like this...

When Ada was being designed, the term "thread" was not current.  So when
when Ichbiah et al chose the word "task", they weren't choosing a term
that was "different".  They were just choosing a word that made sense.
They'd probably read the same OS textbook as you :-) :-).  Indeed, the
term "multitasking" has been current all along.

In the '80s there was research going on, at Sun Microsystems and
elsewhere, on "lightweight processes".  For a while there it looked like
"thread" and "lightweight process" were being used interchangeably in
the literature, the former evidently arising out of the desire for a
less cumbersome term -- though in the final elaboration of Sun's thread
model (and maybe DEC's too, I'm not sure) the term LWP was retained as
the name for a different abstraction.  The LWP is the unit of scheduling
onto physical processors (e.g. in a multiprocessor system), and threads
are then scheduled onto LWPs.  But had the impression that this
two-level architecture came later and had nothing to do with the origin
of the term "thread".

So maybe they should have called them "tasks" instead of "threads", so
that they could be using the same term as Ada? :-)

> There are at least two good ways to proceed within the Ada community.
>
> 1) Change the Ada terminology to agree with the POSIX (and C) terminology.
> This has the benefits of easier communication, accepting standard
> terminology, and (slightly) easier learning of Ada.  Allow "thread" to be
> used in any place where "task" is now allowed (add one more reserved word).

Well... they're called tasks in Ada and I would guess that that's just
how it's gonna be.  It's pretty hard to justify adding a new reserved
word that is a synonym for an existing reserved word, whatever the
reason.  So I think it's a stretch to call this a "good" alternative... :-)

> 2) Use the Ada terminology consistently.  This separates us from the C
> world (this is a good thing).  It agrees with history.  It does not create
> a new reserved word.

Sure, I would agree that the term "thread" shouldn't be used to refer to
an Ada task...  Is that what you mean?  I've never seen that usage
before, and it wouldn't occur to me to call an Ada task a "thread"...
Are there many examples of this misnomenclature?