Ada replacements for DOS I/O

Ada replacements for DOS I/O

[Elgar the Idiot aka Chris Warwick]

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

Does anyone know of any replacements for the DOS I/O (specifically the Disk 
I/O operations) compatable with Alsys Ada?
 --
 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: Ada replacements for DOS I/O

[Robert Dewar]

The failure to do concurrent I/O is certainly not a bug (nothing in the
Ada standard requires, or even implies, that I/O done from one task is
concurrent with the execution of other tasks).

Furthermore, using DOS I/O, such concurrency is very hard to achieve, since
DOS is basically single threaded, and any processing that continued during
I/O would have to promise not to use ANY DOS calls at all explicit or
implicit, not so easy to arrange, and even with this restriction, it is
very difficult to arrange for this kind of concurrent I/O under DOS>

If you need concurrent I/O, put an operating system on your PC (many
choices including OS/2, NT, Solaris, SCO Unix, Linux, BSD386, Lynx,
Nextstep), and then shop for a compiler that definitely supports the
concurrency that you need.

You burned yourself on this one by making a totally unwarranted assumption!

Re: Ada replacements for DOS I/O

[Ted Dennison]

In article <44279.cwarwick@fox.nstn.ns.ca>, "Elgar the Idiot aka Chris Warwick" <cwarwick@fox.nstn.ns.ca> writes:
|> 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...
|> 
|> Does anyone know of any replacements for the DOS I/O (specifically the Disk 
|> I/O operations) compatable with Alsys Ada?
|>  --
|>  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

Don't be so hard on Alsys (at least not for this). I know of NO Ada system
on any platform that handles tasks and I/O that well. VAX Ada comes close, 
but simultanious Text_IOs will kill the application. Tasks and I/O are 
NEVER a no-brainer.

There are several issues with tasking that can burn you. Your only real
protection is to investigate how these things work BEFORE you start coding.

As to your current problem, you will have to use low-level OS I/O calls that
do not block waiting for completion. If your OS (MeSsy-DOS?) does not have 
them, get another OS and/or platform, or live with it.

T.E.D.

Re: Ada replacements for DOS I/O

[tmoran]

About a year ago the local SigAda presentation by someone from
Sun or Silicon Graphics (I forget which) was about a compiler
that let you specify which tasks should be separate OS threads,
and thus not block other threads when they do IO, and which tasks
should be Ada run-time multitasked within a single OS thread,
and thus do task switching much faster.  Thus letting you
'pays your money and takes your choice'.

Re: Ada replacements for DOS I/O

[cwarwick]

On 27 Oct 1994 19:04:50 -0400, 
Robert Dewar  <dewar@cs.nyu.edu> wrote:

>The failure to do concurrent I/O is certainly not a bug (nothing in the
>Ada standard requires, or even implies, that I/O done from one task is
>concurrent with the execution of other tasks).

No, but it does require a higher priority task take precedence over a 
lower. With the Alsys DOS product all task processing regardless of 
priority ceases. I think the nature of Ada tasking is such that I/O be at 
least interruptable when a higher priority task becomes ready to run.

>If you need concurrent I/O, put an operating system on your PC (many
>choices including OS/2, NT, Solaris, SCO Unix, Linux, BSD386, Lynx,
>Nextstep), and then shop for a compiler that definitely supports the
>concurrency that you need.

The most logical step is of course to write the IO functions we need in 
Ada (or find someone who already has, hence the start of this thread) and 
then the bug goes away, regardless of operating system...

>You burned yourself on this one by making a totally unwarranted assumption!

I don't think its unwarrwanted. Alsys provided use with all the OS tools we 
needed to implement this project, which included interrupt handling, 
multiple tasking, and IO to nonstandard cards. I don't think given all this 
it was unreasonable to assume they had thought about the interaction 
between tasks and DOS.
 --
 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: Ada replacements for DOS I/O

[Robert Dewar]

Of course simultaneous text_io from separate tasks to the same file (e.g.
standard output) is pretty hard to define anyway (at what level does the
output get interleaved - lines, text_io calls, characters, pixels?)

Re: Ada replacements for DOS I/O

[Mark Bayern]

 
In article <38pbmi$4n9@schonberg.cs.nyu.edu>, Robert Dewar (dewar@cs.nyu.edu) writes:


>
>You burned yourself on this one by making a totally unwarranted assumption!
>

Yes, but lets be clear what burned him.  Not Alsys Ada, but making
assumptions about MS-DOS's capabilities!

Mark
 

Re: Ada replacements for DOS I/O

[tmoran]

>The most logical step is of course to write the IO functions we need
There are two problems: traditional hard disk IO in DOS is done via
CPU instructions, not DMA, so it's not convenient to interrupt in
the middle - and you couldn't get much IO/CPU overlap anyway.
The more general problem is that MSDOS is not re-entrant.
So the effect is as if there is a single (DOS) task that does
any and all DOS activity.  Any task wanting a DOS action must
wait for rendezvous with that single DOS task.
  The first problem is lessened under DOS by doing disk IO with
large block sizes, full track reading, disk caching, etc.
For the second problem, you'll have to write your own multi-tasking
DOS.  A non-trivial undertaking.  (OTOH, IBM and Microsoft have
already done that and sell the results as OS/2 and Windows NT. ;)
  Is your problem that you would like useful CPU cycles overlapped
with disk IO, or that (presumably due to interrupts) high priority
tasks can suddenly become unblocked while a low priority task is
running inside non-preemptible DOS?

Re: Ada replacements for DOS I/O

[David Emery]

>I know of NO Ada system on any platform that handles tasks and I/O
>that well.

The reason is that it's not a compiler problem, but rather an
operating system problem.  Ada cannot be held responsible for
shortcomings in operating systems.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Ada replacements for DOS I/O

[David Weller]

In article <EMERY.94Nov1144245@goldfinger.mitre.org>,
David Emery <emery@goldfinger.mitre.org> wrote:
>>I know of NO Ada system on any platform that handles tasks and I/O
>>that well.
>
>The reason is that it's not a compiler problem, but rather an
>operating system problem.  Ada cannot be held responsible for
>shortcomings in operating systems.
>

Especially one the isn't an OS, but rather a file system with a bad
attitude. :-)

-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Ada replacements for DOS I/O

[Robert I. Eachus]

In article <38qq4u$as2@theopolis.orl.mmc.com> dennison@romulus23.DAB.GE.COM (Ted Dennison) writes:

 > Don't be so hard on Alsys (at least not for this). I know of NO Ada system
 > on any platform that handles tasks and I/O that well. VAX Ada comes close, 
 > but simultanious Text_IOs will kill the application. Tasks and I/O are 
 > NEVER a no-brainer.

   There are several versions of the Verdix compiler targeted to
multi-processor systems which do this, and do it very well.  The first
was for the National chip-based Sequent machines.  And the same
run-time has been ported to several other systems.

   But this is, and always has been, an issue outside the scope of the
language.  If the operating environment supports multiple processes
doing I/O to the same devices at the same time, it is nice to have a
compiler which recognizes that and takes advantage.  But the overhead
to do that under "vanilla" Unix is harsh, and under MS-DOS it is darn
near impossible.

   But it has always surprised me that (especially on Unix) no vendors
have built their I/O packages around a "two process" model.  The main
program and all user defined tasks run in a single process, but you
have a package that mediates all I/O events and hands them to a second
process which does the waiting and event handling.  If done right,
most of the I/O can be done no wait from the point of view of the
second process, and only the task in the main program which made the
call does the waiting.

   While such a run-time may be overkill for most programs, the amount
of code that needs to be changed is small, and usually buried in one
or more implementation defined packages.  It shouldn't be hard for a
vendor to do a switchable implementation, and allow the user to switch
at link-time.  Or, if you are adventurous, it is about a three week
effort if you have access to the source code for the implementation
defined library units.  (Yes, I've done it.)  Of course, GNAT is going
for a full threads based run-time, but even in GNAT, this style of
run-time would better serve most users in some environments.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada replacements for DOS I/O

[tmoran]

>... built their I/O packages around a "two process" model.  The main
>program and all user defined tasks run in a single process, but you
>have a package that mediates all I/O events and hands them to a second
>process which does the waiting and event handling.
As I recall from writing a DOS RAM disk driver many years ago, DOS
device drivers are structured with two calls, one to start (or queue)
the operation, and one to get the result.  So the single tasking must
come from broken implementation somewhere, not broken device driver
interface design.
('All your problems will be solved by Windows xx, from the company
that brought you MSDOS!') O.O

Re: Ada replacements for DOS I/O

[Robert I. Eachus]

In article <392r15$gl3@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

 > Of course simultaneous text_io from separate tasks to the same file (e.g.
 > standard output) is pretty hard to define anyway (at what level does the
 > output get interleaved - lines, text_io calls, characters, pixels?)

   Characters, Robert, characters. ;-)

   More seriously, chapter 14 is written to require, at worst, that
gets and puts of individual characters be treated as indivisible
actions.  Any reasonable tasking aware version of TEXT_IO can and
should lock at a higher level, but it is almost impossible to treat
Text_IO calls as atomic.  (For example, a read of a number can require
reading thousands of bytes from the external file.)

   When I've written tasking aware versions of Text_IO (usually by
revising the vendor supplied I/O routines and calling the result
Nice_IO or Tasking_IO), the locking granularity was either a line of
text or a text_io call, whichever was smaller.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada replacements for DOS I/O

[Robert Dewar]

Mark says:

"Yes, but lets be clear what burned him.  Not Alsys Ada, but making
assumptions about MS-DOS's capabilities!"

no, that's not really right. even if you are using a wonderful multi-threaded
operating system with fully overlapped I/O, you cannot assume that an Ada
compiler will give access to this capability. THere is no requirement for
how Ada tasks map to an operating system, this is an implementation
dependent choice.

Even with an operating system with multiple-threads, it may make perfectly
good sense to map all Ada tasks to a single thread if tasking performance
is more important than I/O overlap. 

So the moral is, don't make *any* assumptions about how Ada tasks will map
to an OS, ASK!

Re: Ada replacements for DOS I/O

[Bevin R. Brett]

In article <38qq4u$as2@theopolis.orl.mmc.com> dennison@romulus23.DAB.GE.COM (Ted Dennison) writes:

> Don't be so hard on Alsys (at least not for this). I know of NO Ada system
> on any platform that handles tasks and I/O that well. VAX Ada comes close, 
> but simultanious Text_IOs will kill the application. Tasks and I/O are 
> NEVER a no-brainer.

We (DIGITAL) are unaware of ANY problems with doing simultanious Text_IOs with
VAX Ada, and believe it works.  Have you reported them to us?

/Bevin
DEC Ada team

Re: Ada replacements for DOS I/O

[Robert Dewar]

The limitation in DOS on simultaneous I/O has nothing to do with device
drivers, it comes from the fact that the Int 21h handler is single
threaded!

Re: Ada replacements for DOS I/O

[Samuel Tardieu]

>>>>> "Robert" == Robert Dewar <dewar@cs.nyu.edu> writes:

    Robert> So the moral is, don't make *any* assumptions about how
    Robert> Ada tasks will map to an OS, ASK!

Ask ? Ok :-) How are tasks implemented in Gnat when running on a
multi-threaded OS (Solaris for example) ? And on SunOS, which
has lightweight processes ? Will it use the public/domain pthreads library ?

Thanks in advance for your answer.

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Ada replacements for DOS I/O

[Robert Dewar]

I don't see where chapter 14 is wriotten to require proper interleaving
of characters ???

Re: Ada replacements for DOS I/O

[Robert Dewar]

I think I have posted this before, but since it is asked again, here goes.

Implementation of tasking in GNAT. The Tasking is based on a low level
interface for which we currently have posix threads and OS/2 threads
implementations (the latter is in final testing before being released).
THe threads implementation can map either to read pthreads, e.g. on the
SGI, or to a pthreads simulator we have for SunOS. The latter is in C,
but is not yet very portable, it really assumes it is on a Sun.