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?