From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4141813e8c986e25,start X-Google-Attributes: gid103376,public From: "Kevin J. Weise" Subject: tasking post to comp.lang.ada Date: 1996/06/06 Message-ID: <4p6pag$e3j@michp1.redstone.army.mil>#1/1 X-Deja-AN: 158781595 to: tat115@psu.edu content-type: text/plain; charset=us-ascii organization: Redstone Arsenal, Alabama mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.22 (Windows; I; 16bit) Date: 1996-06-06T00:00:00+00:00 List-Id: 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,