From: "Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil>
Subject: tasking post to comp.lang.ada
Date: 1996/06/06
Date: 1996-06-06T00:00:00+00:00 [thread overview]
Message-ID: <4p6pbg$e3j@michp1.redstone.army.mil> (raw)
tat115@psu.edu (Tod Trowbridge) wrote:
>
> I just started programming in ada and have a general
>question about tasking.
>
> I have a task in a package. If a procedure that withs
>that package calls the task, does the task have to be waiting
>at the accept statement, or will the procedure wait for the
>task to get there.
>
> Any help in this matter would be greatly appreciated
>
> Thanks
Tod:
I suspect your question is a bit deeper than you think. It sounds to me as if you
are asking when the task in the package gets activated as well. This is done during
the process of the package's elaboration, which gets done before control ever
reaches your procedure. It doesn't matter if your procedure is the main program or
a library unit, since both it and the package are in the closure of your program.
Now, as to whether the procedure or the task waits for the other one is dependent
upon other aspects of your program and your environment. Presumably, the procedure
you refer to is in a different thread of control than the task (the "main program"
establishes, if you will, the main task in a multi-tasking program).
Let me presume your program is running on a uniprocessor machine (ie. your
computer has a single CPU). If your task is simple (i.e., it only has one entry
point) and the tasking kernel switches from one task to another when the task in
control "blocks" (i.e. for I/O, or for rendezvous), it is likely (but not absolutely
true) that the thread of control in which the procedure is executing has the
processor because the task is waiting at its entry point (i.e., the task gave up
control of the processor to wait at its entry point). If the task has multiple
entry points, its possible that the task is waiting on a different one than that
which the procedure is invoking. If there is no other task to satisfy that
rendezvous, then you have a deadlock (i.e. the procedure is attempting to rendezvous
at one entry point, but the task is waiting for rendezvous at a different one, with
no way for either to change). If your tasking kernel uses time slicing to
distribute use of the processor over multiple threads of control, then its possible
that the task is not even waiting at an entry point at the time the procedure is
attempting to rendezvous with it.
If your program is running on a multi-processor system, it is possible for your task
and main program to be running concurrently; there is no way to know which one will
wait for the other.
I hope this isn't too confusing. It is, however, the nature of timing-related
issues in computing whether you are using semaphores, monitors, or rendezvous. If
you have more questions, or need further clarification, ask your instructor or send
me more email.
Kevin J. Weise kweise@colsa.com
COLSA Corp.
6726 Odyssey Drive
Huntsville,
next reply other threads:[~1996-06-06 0:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-06-06 0:00 Kevin J. Weise [this message]
-- strict thread matches above, loose matches on Subject: below --
1996-06-06 0:00 tasking post to comp.lang.ada Kevin J. Weise
1996-06-06 0:00 Kevin J. Weise
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox