jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342) (01/12/88)
Mike Feldman (MFELDMAN@GWUVM.bitnet) writes "I have the fairly clear
impression that TEXT_IO wasn't really intended to be used inin a tasking
environment." I don't see why TEXT_IO is any different from any other
I/O package in a tasking environment. Any tasking rpogram which accesses
a file from two (or more) tasks has to be careful. Section 9.11 applies.
Implemetations which block all tasks when one does I/O to standard_input
or standard_output are "protecting" programmers from the ill-effects of
writing erroneous programs, because a whole bunch of people wrote erroneous
programs (the example Mike gives is one task doing PUT("ABC") and another
doing PUT("DEF") with the screen result ADBECF) and complained when the
implemenation did the unexpected. Section 9.11 says that if one task
updates a shared variable, another should not without explicitly synchron-
izing with the first. standard_output is a shared variable.
It seems clear to me that part of the pijt of allowing tasking in a single
processor environment is to continue computing while the guy at the
terminal is scratching his head. This mandates context switching at I/O
points. I hope that there is no AdaBoard policy which opposes this view.
Jim.flynn@acf2.UUCP (Susan Flynn) (01/15/88)
P. S. Tuffs writes: >Help! ... > I came across a problem on the > Alsys system where once entry of a data field was started, the other > tasks in the system freeze, and the PC seems to be totally dedicated to > handling the user input. ... > What gives? Am I missing something big, or does Ada not care whether a > single task performing Text_IO calls can block the reset of a system? ... > I would appreciate any > comments on this dilemma. Goes on to gives an example program including the declaration: Shared_Variable: Integer := 0; Jim Moody explains: ... > Section 9.11 says that if one task > updates a shared variable, another should not without explicitly synchron- > izing with the first. standard_input is a shared variable. ... So is Shared_Variable and it is for precisely this reason that the program as written is erroneous and all of the compilers tested behave correctly: Shared_Variable is not declared in a pragma SHARED; Task_A and Task_Blk do not synchronize until the rendezvous Stop; therefore, it is erroneous for BOTH tasks to be accessing Shared_Variable before the rendezvous. (Further, the effective store of Shared_Variable need not be done by A_Task until the start of the rendezvous, so it is perfectly legal for Shared_Variable to have the value 0 before that time.) However, I doubt that the compilers would behave differently if a pragma SHARED(Shared_Variable) statement was added -- most uniprocessor compilers do not differentiate between shared variables that are declared in a pragma SHARED and those that are not. I was not surprised that many of the compilers did not context switch when a task does I/O, but I was surprised that adding priorities did not help, since Ada requires a preemptive scheduler, i.e. it cannot be the case that a task of lower priority is running while a ready-to-run task of higher priority is not. (Does the Meridian compiler use the trick of only supporting a single priority so that any scheduling discipline vacuously satisfies this requirement?) Susan Flynn flynn@acf2.nyu.edu Relay-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU From: dube@acf3.NYU.EDU Date: 14-Jan-88 18:34 EST Date-Received: 14-Jan-88 18:34 EST Subject: Re: Heightism Message-ID: <22460001@acf3.NYU.EDU> Path: acf3!dube Newsgroups: soc.women Posting-Version: version nyu B notes v1.5 12/10/84; site acf3.NYU.EDU Organization: New York University References: <11604@sri-unix.SRI.COM> I read an article about height v. salary among U.S. men. Taller meant more money, up to 6'4", at which point it started slowly decreasing. Typically, the victorious Presidential candidate in November is taller than the loser. Ira Kaplan