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,552fa40a9acfc28f X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Tasking and blocked threads Date: 1999/09/10 Message-ID: #1/1 X-Deja-AN: 523396841 Sender: bobduff@world.std.com (Robert A Duff) References: <37D849AE.AC5EA4F1@res.raytheon.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-09-10T00:00:00+00:00 List-Id: Andy Askey writes: > the STANDARD Ada95 model and the THREADED Ada95 model with Apex 3.0.0b > on a Solaris 2.6 OS. The output from the STANDARD model swaps between > tasks alternating grouped lines of output. A bunch of "in task one" > lines are followed by a bunch of "YOMOMMA!!!!!" lines. I was told that > this was due to time slicing in the STANDARD model. Formally, the execution of this program is erroneous, and therefore completely unpredictable, because two tasks are simultaneously writing upon the same variable (the current output file). So the compiler can do whatever it likes. Probably what's actually going on is that the I/O causes the tasks to block. That's allowed (and usually desirable). Replace the I/O with some in-memory manipulations of data structures, and see if the behavior changes. Of course, an implementation can provide whatever task dispatching policies it likes; the run-till-blocked semantics is part of the Real Time Annex. - Bob -- Change robert to bob to get my real email address. Sorry.