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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!nike!ucbcad!ucbvax!NADC.ARPA!prindle From: prindle@NADC.ARPA Newsgroups: net.lang.ada Subject: re: Sharing processor between tasks Message-ID: <8609261139.AA14947@ucbvax.Berkeley.EDU> Date: Wed, 24-Sep-86 16:19:03 EDT Article-I.D.: ucbvax.8609261139.AA14947 Posted: Wed Sep 24 16:19:03 1986 Date-Received: Fri, 26-Sep-86 21:00:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: Following up on this subject, it should be obvious that, even *if* the run-time support for a particular compiler *does* time-slice tasks, the program as given might not work correctly. If "put();" were implemented as a library routine which did a series of "put();" calls, then it would be reasonable to expect the output to appear as: horveirzonttical alhorizonve........ The technically correct way to do this kind of thing is to consider the device being written to as a resource and manage this resource with a third *server* task. Only this third task would be allowed to do "put"s to this device, and would contain an accept for an entry call which passes a string to be written. Only in this way could it be guaranteed that each string is written without probability of another string interrupting it. This is especially important when using "escape" sequences which cannot be arbitrarily split up. This *server* task approach has the desirable (I think, for the original poster) side effect of perfectly interspersing the strings, since, while one string is being printed, the task outputting that string is ineligible for execution and the other task will deposit it's request to output the other string on the server's entry call queue. Try it - it really works! Frank Prindle Prindle@NADC.arpa