Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O)

[CONDIC@PSAVAX.PWFL.COM]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O)
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



>"Bennett, Chip (KTR) ~U" <BennettC@J64.STRATCOM.AF.MIL> wrote:
>
>Chris Warwick <cwarwick@FOX.NSTN.NS.CA> wrote:
>
>> We just got burned on a project using Alsys Ada. Seems we had assumed that
>> a multi-tasking Ada program would perform I/O is parallel with other
>> processing. The system service call actucally halts all processing in the
>> program until the system service is complete...
>
>> I don't mean to burn Alsys, since the bug(?) also exists in the Verdix
>> compiler we are using. The difference is the Verdix is for Unix so we just
>> sidestepped the problem by not using Ada tasks...
>
>We use SunAda (aka Verdix) with Motif.  Does this mean that if an
>application is drawing to the screen and number crunching at the same time
>in a separate Ada task, that the "background" task is going to be suspended
>for the same I/O interrupts that the "foreground" task is being suspended?
>
>Does everyone else consider this acceptable, or am I the only one that is
>appalled?

In my experience with DEC Ada for VAX/VMS, the same problem
occurs. If a task performs an I/O operation, the runtime system
does not consider the task blocked and thus has no reason to
start running other tasks.

I believe that we fixed this problem by juggling task priorities
so that I/O tasks were at the bottom of the list, but I don't
recall if the preemptive scheduling was able to interrupt the
pending QIO. The only way to successfully fix this would have
been to dip into very serious system calls within the context of
the task to shoot the QIO in the head in the event that there was
nothing pending. This may have been what we did, but it's been
such a long time now and my two or three remaining brain cells
have a hard time executing a successful "rendezvous"

I don't know as I'd call this a "bug" because Ada never specified
a scheduling algorithm, nor was I/O ever explicitly considered as
some sort of tasking structure which would require the task to be
blocked. (A call to "TEXT_IO.GET (ITEM => X);" was never
specified to behave as the execution of "wait 1.0;" or "accept
THIS_ENTRY;) Hence an implementation could legally consider the
task to be running - not blocked - and do nothing to preempt it.

I share your frustration in that it would be *extremely* handy
for a task to be considered blocked or ready whenever the
underlying operating system would consider a process blocked or
ready. However, I can understand the difficulty of actually
getting this to work. It isn't always easy to design an Ada
runtime kernal and have it match up nicely with an underlying
operating system that wasn't designed to deliberately support
Ada.

Pax,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "I like to dive around in my money like a porpoise and burrow
    through it like a gopher and toss it up and let it hit me on the
    head."

        --  Scrooge McDuck
===============================================================================