Roger Racine wrote: > ... > I have seen some discussions about Ada tasks vs POSIX threads, and was > surprised to see someone suggesting that they are not synonymous. 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. > > This looks like an interesting attempt at re-writing history, since I would > be surprised to find any references to "thread" prior to Ada's first usage > of the term "task". And the Rationale for Ada83 uses the same definition > as was in my text book ("a computation that may be done concurrently with > other computations"). While it is true that if one uses the POSIX services > to create a thread, then a thread is really created, it would be difficult > to say there is really an Ada task if the compiler optimizes it away (it > might be in the source code, but the debugger would not think it existed). In talking about an Ada run-time, I personally find it useful to talk about Ada tasks, and underlying OS threads as somewhat distinct concepts. In particular, deleting and creating OS threads can be expensive, so we tend to reuse OS threads to support shorter-lived Ada tasks. There are also situations where multiple Ada tasks share a single OS thread at the same time, with switching between the two handled by the Ada RTS rather than the underlying OS. It is probably true that this is revising history, but it is a useful revision. Interestingly, we have one target where we have Ada tasks at the highest level, kernel threads at an intermediate layer, and OS tasks at the lowest level. In this case, we have to always say "Ada task" to distinguish them from "OS task." So at least in the POSIX environment, it is convenient to have two different terms, one to be the higher language-level concept, and one to be the lower implementation-level concept. This is similar to Ada's fixed-point types, or Ada's enumeration types, which are implemented by underlying machine integers in most implementations. > > 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). I can't imagine doing this. This would just add to the confusion in my view. > > 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. I'm not sure what you mean by using the terminology "consistently." Clearly an Ada task is an Ada language construct. It may or may not have a one-to-one relationship with underlying OS threads. > By the way, it is interesting that Linux uses the word "task" in its > implementation of process functionality (including threads), and at least > one Ada vendor uses "thread" in runtime system routines implementing tasks. We do that. Perhaps others do as well. As mentioned before, we reuse threads to support shorter-lived Ada tasks. Also, we free up a thread for reuse as soon as an Ada task terminates, and we don't allocate the thread until the Ada task activates. So the association between an Ada task and an underlying OS thread is shorter than the lifetime of the Ada task (object). From a teaching point of view, the distinction is probably irrelevant. In fact, if you read the first paragraph of RM95 chapter 9, you will find an Ada task defined as a "... thread of control ...". On the other hand, in 9.5.3, it says that the body of an entry may be performed using any thread of control, making perhaps a subtle distinction between Ada task and thread of control. Finally, note that the "Habermann-Nassi" optimization designed as a way to optimize the implementation of Ada 83 rendezvous was all about using the *thread* of control normally associated with the caller task to perform the body of an accept statement, even though "officially" it is the acceptor *task* that is running during the rendezvous. > Roger Racine > Draper Laboratory, MS 31 > 555 Technology Sq. > Cambridge, MA 02139, USA > 617-258-2489 -- -Tucker Taft [log in to unmask] http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA