synchronous v. asynchronous I/O

synchronous v. asynchronous I/O

[Jim Moody, DCA C342]

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.

Re: synchronous v. asynchronous I/O

[Susan Flynn]

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