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
> 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
-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