From: jcallen@Encore.COM (Jerry Callen)
Subject: Ada and OS tasks (was Ada and Unix Sockets)
Date: 21 Nov 90 16:05:11 GMT [thread overview]
Message-ID: <13325@encore.Encore.COM> (raw)
In-Reply-To: 1990Nov20.205819.24040@sctc.com
In article <1990Nov20.205819.24040@sctc.com> stachour@sctc.com (Paul Stachour) writes:
>[ Interesting article on whether or not Ada runtimes should map Ada tasks
to underlying OS tasks/thread/processes/etc. ]
I've worked on Ada runtimes that did it both ways. Generally, you have more
flexibility if Ada tasks use the underlying OS tasks, but you pay a price in
overhead; how much depends upon the system.
Paul missed a few issues; here are some more:
- The underlying OS may not provide much, if any, control over task scheduling,
which renders Ada priorities meaningless.
- The OS may not provide much in the way of locking primitives; building your
own (with, say test and set and spin locks) may prove problematic. For
instance, suppose a task holding a lock is blocked by the OS and another
task tries to get the lock? You can burn a lot of CPU in spin locks.
This is important because a multi-threaded Ada RTS is going to make
heavy use of locking.
- How do Text_IO and the other predefined Ada I/O packages behave in the
presense of tasks? Making them "do the right thing" may entail a lot
of overhead that most programs don't need. (My vote: control via the
forms string.)
So how have various Ada implementations done it? Here are a few I am familiar
with; I'd love to see folks post more. I have a lot of IBM/370 experience, which
is reflected in the following list...
- Intermetrics MVS Ada: one Ada task per MVS task. Task create times are
unpleasantly long, but rendezvous isn't bad; as Paul pointed out, all
I/O in MVS is inherently asynchronous, so the OS provides reasonably
efficient "wait/post" primitives. Since MVS runs on multiprocessors, it
is possible to really have multiple Ada tasks executing simultaneously.
Shared memory isn't a problem since MVS tasks share an address space.
- Intermetrics CICS Ada: one Ada task per CICS task. I don't have any idea
how well it performs.
- Telesoft MVS Ada: mapping controlled by pragma; I don't have details.
I would expect the performance to be similar to the Intermetrics RTS (at
least regarding OS task create/rendezvous times).
- current Encore Ada (uses Verdix technology): two schemes available. The
"sequential" Ada is the usual "one Unix process for the whole program"
approach, with the Ada RTS handling dispatching. The "parallel" Ada
allows a variable number of Unix processes to be allocated to a program,
which the RTS multiplexes among the Ada tasks; it's sort of a hybrid of
the two usual approaches. Memory is shared via Unix shared memory
facilities. I/O is funnelled through a single I/O process.
- forthcoming Encore Ada (for Encore 88K based systems): one "very lightweight
process" (thread, really) per Ada task. All threads share an address space.
I'm currently working on this implementation; needless to say, it runs like
a bat outta hell. :-)
-- Jerry Callen
jcallen@encore.com
next prev parent reply other threads:[~1990-11-21 16:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1990-11-19 4:15 Ada and Unix Sockets Bradley Schmerl
1990-11-20 20:58 ` Paul Stachour
1990-11-21 16:05 ` Jerry Callen [this message]
1990-11-23 13:19 ` Ada and OS tasks Jean-Loup Gailly
1990-11-26 12:34 ` Ada and Unix Sockets Dennis Gibbs
1990-11-29 22:59 ` Jean-Marc Alliot
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox