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

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

[Bennett, Chip (KTR) ~U]

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?

*****************************************************************
* Chip Bennett, GDE Systems Inc | BennettC@j64.stratcom.af.mil  *
* USSTRATCOM/J64213             | Voice (402)294-7360           *
* 901 SAC Blvd, Suite 2B24      | FAX   (402)294-7912           *
* Offutt AFB, NE 68113-6600     | Opinions expressed are my own *
*****************************************************************

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

[Robert Dewar]

THe important thing to realize is that the Ada language has nothing to
say about whether I/O operations allow other tasks to proceed, nor could
it, since this is a highly operating systems dependent feature. In some
operating systems (e.g. DOS) it is close to impossible to do overlapping.
In a Unix without threads, it is also difficult. 

In a Unix with threads, you cannot assume that Ada tasks are mapped to
different threads. If they are, then almost certainly I/O is overlapped.

THe bottom line here is that you need to ask specific questions about
your implementation before making assumptions that are unwarranted. If
you require overlap, then make sure that your implementation supports it.

Calling it appalling or a bug, or whatever is really besides the point. THere
are many implementation dependent features in Ada (or in C or Fortran for
that matter), and one of the jobs of any programmer in any language is to
make sure that the compiler you are using supports the features that you
required.

Note that even in DOS, there are *some* cases where overlap can be achieved.
FOr example, it is definitely possible and desirable (though not required!)
to allow overlap of tasks with keyboard I/O, but disk I/O is pretty much
a lost cause.

Going back to the threads issue, it is very important for you to know
whether you need your Ada tasks mapped to threads, and if so, to insist
on this mapping. Typically mapping Ada tasks to threads introduces a lot
of extra overhead (light weight threads in most Unices aren't!) so a vendor
may assume that high performance on tasking is more important than this
mapping, and that decision may be right, it all depends on expectations
and planned usage.

In GNAT, we base our tasking implementation on posix threads. On a system,
like SunOS, which has no threads, we simulate the threads. This means that
we expect to take advantage of multiple threads if the operating system
provides them, and the implementation of GNAT tasking on the SGI does map
to separate threads.

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

[Rudy Zijlstra]

"Bennett, Chip (KTR) ~U" <BennettC@J64.STRATCOM.AF.MIL> writes:

>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?

The problem you have i running two shedulers above each other. The OS 
schedeuler and the Ada internal scheduler. The OS scheduler knows
<nothing> about the fact that you are multithreaded (or however you want
to call it) and when the Ada (multi)task performs a (blocking) I/O, the
OS scheduler correctly blocks it. Keep in mind it knows (righly and
correctly) nothing about the Ada scheduler.... In other words, unless
you are running Ada 'native' on the target hardware, i.e. without
supporting OS, don't use tasking in Ada unless you are prepared to
accept penalties like these.

Rudy Zijlstra

#include <stddisclaimer.h>       This might not be the view of my employer.

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

[cwarwick]

On Fri, 28 Oct 1994 11:59:00 PDT, 
Bennett, Chip  <BennettC@J64.STRATCOM.AF.MIL> wrote:

>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?

Well my experiments under SCO and Verdix have shown me that a blocking OS 
call, i.e. READ, will halt both the foreground and background task until it 
has completed... (my data is not yet complete, when I hit the problem on 
DOS I went over and quickly checked on the SCO box)

>Does everyone else consider this acceptable, or am I the only one that is
>appalled?

I don't hold any view. My plan is to switch to Unix processes on the SCO 
and avoid the problem altogether... so much for system independance
 --
 Lorne Elliot in a Conan the Barabarian suit, or
 "Beware the fool, for only the fool may speak the truth"

 Chris Warwick
 cwarwick@fox.nstn.ns.ca
 warwick@anchor.hfx.prior.ca

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

[CONDIC]

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
===============================================================================

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

[R. William Beckwith]

Bennett, Chip (KTR) ~U (BennettC@J64.STRATCOM.AF.MIL) wrote:

: 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?

If you are on SunOS 4.1.3, a blocking I/O will stop your entire process.
Xt (called by Motif) does a Unix select call on the file descriptors for
connections to the displays.  This stops the process.

This is why we went to so much trouble in Screen Machine to run the
Motif code in a separate process.  There are a couple of rules to
follow (if you're not using Screen Machine ;-) that will help:

    1. Poll for events by calling XtAppPending to check if an event
       exists before calling XtAppNextEvent

    2. only call Xlib/Xt/Motif from one task,

    3. pray

Dan Heller's Motif book (O'Reilly) has a real nice chapter on using
Unix signal handlers with Motif.  It is a very nice discussion of
threading with Motif.

BTW, OSF is probably not going to make Motif thread safe anytime
soon (if at all).

: Does everyone else consider this acceptable, or am I the only one that is
: appalled?

It's ugly, but not Ada's fault.  Some O/S's (IRIX, Solaris, OSF/1,
OpenVMS/AXP, Win NT, Lynx, et al) have finally caught up to Ada.
Ada did multi-threading before the O/S's, GUI's, etc. could
really handle it.

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in