comp.lang.ada
 help / color / mirror / Atom feed
* Re: tasking, Cpu's, and more
  1999-09-10  0:00 tasking, Cpu's, and more G
@ 1999-09-10  0:00 ` Mark Lundquist
  1999-09-10  0:00 ` Marin David Condic
  1 sibling, 0 replies; 3+ messages in thread
From: Mark Lundquist @ 1999-09-10  0:00 UTC (permalink / raw)


G wrote:

> Hi all... I am back on topic now... so please forgive my brief
> outbursts of vociferous humanity...
>
> 1) If a program runs several tasks and the hardware has several CPU's.
> Does the whole
> process of coding the tasks require that a specific CPU is allocated to
> each one ?

Not necessarily....

>  I can understand how different threads of activity can be
> happening in different places, it just appears something less than
> transparent whether or not tasks must be assigned to system-specific
> CPU's.  This is a theoretical issue, I suppose.  I wonder because it
> might
> appear (to the novice/ interested individual) that different tasks
> performing different
> processes would require different coding for the relevant hardware
> functions and thus the task would have to be identified (in some way or
> another) with the relevant processor.  (?).  Is this so ?  If not, how
> would it be possible to ensure that a task
> was carried out in the right place ?   Does the code have to be written
> with hardware targets for the tasks ?

You might want to take a look at the RM, Annex E, which deals with
distributed computing.  Note that a single "processing node" as defined in
Annex E may in fact consist of multiple CPUs.  Also, the unit of
distribution is called a "partition", and it is much more general than just
"a task".






^ permalink raw reply	[flat|nested] 3+ messages in thread

* tasking, Cpu's, and more
@ 1999-09-10  0:00 G
  1999-09-10  0:00 ` Mark Lundquist
  1999-09-10  0:00 ` Marin David Condic
  0 siblings, 2 replies; 3+ messages in thread
From: G @ 1999-09-10  0:00 UTC (permalink / raw)


Hi all... I am back on topic now... so please forgive my brief
outbursts of vociferous humanity...

1) If a program runs several tasks and the hardware has several CPU's.
Does the whole
process of coding the tasks require that a specific CPU is allocated to
each one ?  I can understand how different threads of activity can be
happening in different places, it just appears something less than
transparent whether or not tasks must be assigned to system-specific
CPU's.  This is a theoretical issue, I suppose.  I wonder because it
might
appear (to the novice/ interested individual) that different tasks
performing different
processes would require different coding for the relevant hardware
functions and thus the task would have to be identified (in some way or
another) with the relevant processor.  (?).  Is this so ?  If not, how
would it be possible to ensure that a task
was carried out in the right place ?   Does the code have to be written
with hardware targets for the tasks ?  (I am trying to explain what you
already understand, I better refrain from asking the same question in
any more variations... you know what I mean... common language semantics
being so very much more fluid than computer code.)

2) What, exactly does it mean to  "implement a parallel state iterator
in ada with dependency checking" ?

-Graeme








^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: tasking, Cpu's, and more
  1999-09-10  0:00 tasking, Cpu's, and more G
  1999-09-10  0:00 ` Mark Lundquist
@ 1999-09-10  0:00 ` Marin David Condic
  1 sibling, 0 replies; 3+ messages in thread
From: Marin David Condic @ 1999-09-10  0:00 UTC (permalink / raw)


G wrote:

> 1) If a program runs several tasks and the hardware has several CPU's.
> Does the whole
> process of coding the tasks require that a specific CPU is allocated to
> each one ?  I can understand how different threads of activity can be

That depends on what you mean by "coding the tasks". From an Ada source code
level, the whole issue of which processor (real or virtual) is executing
which task is totally invisible. You view it as if each task is somehow
going to magically run on its own processor and the underlying
implementation is going to handle the rest.

If by "coding" you mean the translation of the Ada source to some underlying
machine instructions, the answer is "it depends". If the target machine is
running a conventional operating system like WindowsNT or Unix, then the
compiler will (likely) map the tasks to operating system provided
"processes" or "threads" and the problem of assigning a processor to a
process then belongs to the operating system. How it does that is very
dependent on which OS running on which hardware you want to talk about.

In bare board machines with multiple processors, the answer is "it depends"
even moreso. Sometimes the processors are configured for highly parallelized
execution and sometimes the processors may have very specific, dedicated
jobs to do and communicate with each other very little. For these
situations, you typically end up having to custom modify the run time kernel
(RTK) that the compiler uses to handle its tasking responsibilities. Either
that, or often there are ways of fooling around with link images after
compilation is done (You build separate "main" programs in effect and assign
them to specific processors.). In either event, the tasks may be hard-wired
to specific processors or they may float between processors based on the
first available unit. The choice of which will depend on the hardware
configuration and how much work you want to do in modifying the compiler
implementation.

In any case, from the practical viewpoint of your garden variety application
programmer, all this is invisible and you just presume it happens.

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/






^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-09-10  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-10  0:00 tasking, Cpu's, and more G
1999-09-10  0:00 ` Mark Lundquist
1999-09-10  0:00 ` Marin David Condic

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox