tasking post to comp.lang.ada

tasking post to comp.lang.ada

[Kevin J. Weise]

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, 

tasking post to comp.lang.ada

[Kevin J. Weise]

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, 

tasking post to comp.lang.ada

[Kevin J. Weise]

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,