Asynchronous IO

Asynchronous IO

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

For obvious resons, it is desirable to be able to do output of data to
different devices in parallel. Does the Ada95 standard define what
happens if two tasks try to do IO to two different files at the same
time? I have tried to find out by reading both the RM and the
Rationale, but is none the wiser.

Does one become blocked, waiting for the operation to complete, then
the other becomes blocked, waiting for the operation to complete
(which is what i fear)?
Do both tasks block, then wake up as soon as their respective IO
operations are finished? This is what I would like.
Or, is it simply undefined and left to the implementation?

Ole-Hj. Kristensen

Re: Asynchronous IO

[Robert Dewar]

Kristensen said

"For obvious resons, it is desirable to be able to do output of data to
different devices in parallel. Does the Ada95 standard define what
happens if two tasks try to do IO to two different files at the same
time? I have tried to find out by reading both the RM and the
Rationale, but is none the wiser."

For obvious reasons, it is impossible to find the answer in the RM, since
it depends on the implementation. On a system like DOS, which does not
provide multi-threaded I/O, of course any I/O operation is likely to block
other tasks (sometimes a kludge for keyboard I/O can be arranged, using
polling).

On systems that do provide multi-threaded I/O, you still have to find
out if your implementation takes advantage of this. Take a system like
Solaris, one could do the Ada tasking within one Solaris thread, which
would in fact likely be the most efficient approach for the Ada tasking
itself. However, you would then not get overlapped I/O. One of the reasons
that most people want tasks to map to threads in a system like Solaris,
is precisely to get overlapped I/O, though you then have to check that
the system provides thread-safe I/O (it is amazing in modern Unix systems
with threads how much is NOT thread safe, for instance, malloc is not
thread safe in Solaris).

Re: Asynchronous IO

[Nasser Abbasi]

   From: ohk@edeber.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)

   For obvious resons, it is desirable to be able to do output of data to
   different devices in parallel. Does the Ada95 standard define what
   happens if two tasks try to do IO to two different files at the same
   time? I have tried to find out by reading both the RM and the
   Rationale, but is none the wiser.

   Does one become blocked, waiting for the operation to complete, then
   the other becomes blocked, waiting for the operation to complete
   (which is what i fear)?
   Do both tasks block, then wake up as soon as their respective IO
   operations are finished? This is what I would like.
   Or, is it simply undefined and left to the implementation?

   Ole-Hj. Kristensen


It seems to me that neither Ada nor any other langauge for that matter 
can specify what happens when 2 or more tasks/threads attempt 
access to a shared external system resource such as a file since this 
by its nature, is the resposibility of the operating system (in
particular that of the file system layer) that the program run on top, 
and not the ada-rtl or the ada language. If an ada task issues an 
IO operation, and an other task does the same at about the same time, 
then the file system is resposible for managing concurrent access to 
the file internal data structures and to interact with the device driver
in consistant manner. All what Ada-rtl will do is make calls to the
system lower level calls to do the actual IO, I don't see it doing more than
that in this area. (other than offcourse taking care of
task scheduling after the IO is complete, such as making the task
ready, etc..but that is beside the point).

The behviour should be no different from if 2 or more processes
on the system try to access the same file. The IO operations
will be queued to the file in the order they isseued (in general). If 
it is a blocked/IO operation, the task (or a process) will block untill 
the IO is complete, etc.. even if the 2 tasks each ran on different
cpus in a  multi-cpu system, where an IO operation request can happen 
at exactly the same time, the system is respsible for synchronizing 
access to the device driver.

If the program is an embeded program, where normally there is no
physical files on the board to start with or an operating system
in the normal sense, then access to external devices/ports etc.. 
should be coordinated by the programmer code, either by using protected 
variables or other similar techniques .

I can be competely wrong here becuase I have not also check the RM on
this, but I can bet my house that I have not bought yet that this is
how things would work, and if they don't work like this, then they are
broke :)

nasser

-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server 
application for Nucleic acid and protein sequence search and analysis.
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE, MSCS, MSCE, FM (and Karpov is my chess hero! ..).

Re: Asynchronous IO

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <dewar.834847212@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

   Kristensen said

   "For obvious resons, it is desirable to be able to do output of data to
   different devices in parallel. Does the Ada95 standard define what
   happens if two tasks try to do IO to two different files at the same
   time? I have tried to find out by reading both the RM and the
   Rationale, but is none the wiser."

   For obvious reasons, it is impossible to find the answer in the RM, since
   it depends on the implementation. On a system like DOS, which does not
   provide multi-threaded I/O, of course any I/O operation is likely to block
   other tasks (sometimes a kludge for keyboard I/O can be arranged, using
   polling).

Yes, I also came to this conclusion some time after having posted my
question. I can only say I havn't programmed on systems like DOS fo a
LONG time...

   On systems that do provide multi-threaded I/O, you still have to find
   out if your implementation takes advantage of this. Take a system like
   Solaris, one could do the Ada tasking within one Solaris thread, which
   would in fact likely be the most efficient approach for the Ada tasking
   itself. However, you would then not get overlapped I/O. One of the reasons
   that most people want tasks to map to threads in a system like Solaris,
   is precisely to get overlapped I/O, though you then have to check that
   the system provides thread-safe I/O (it is amazing in modern Unix systems
   with threads how much is NOT thread safe, for instance, malloc is not
   thread safe in Solaris).

I suppose the most reasonable way to make a program using overlapped
IO portable then, would be to define a package to do it, and change
its implementation depending on what kind of system you are running
on.


Ole-Hj, Kristensen

Re: Asynchronous IO

[Nasser Abbasi]

>      From: ohk@edeber.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)

>I am not concerned about concurrent access to the same resource
>(file), but if Ada gives you any guarantees about the degree of
>parallellism if 2 tasks try to access 2 *different* files at the same
>time

... snip..

>After having said this, it occurs to me that the RM cannot make this
>mandatory, as not all environments in which Ada will run has the
>necessary facilities available, I suppose.....

Thats true.  I think I read somewhere on the net a while ago that
GNAT default scheduling policy for a task is run-till-blocked, but
if the platform has its own implementations of threads (as OS/2 threads,
SOlaris, NT et...) then Ada tasks are mapped to the system
threads, and the policy changes, so I guess the degree of parallellism
would depends on the platform. 

one the other hand, there is a paper about GNARL , (the Gnu Ada Runtime 
Library) has as one of its components the Pthreads layer (Posix threads), 
where tasks are implemented as pthreads. So that would be the
place I would think to look to determine the "degree" of
parallellism. GNARL interfaces with Pthreads to requests tasking
services. Offcourse this is on platforms that has Pthreads on it.

GNARL looks like this (from the GNARL paper)

        +--------------------------------+  
        |    Ada program                 |
        +---------------+----------------+
        |               |                |
        |               | Timer services |
        |               +----------------+
        | Ada-run time layer             |
        |                                |
        +--------------------------------+
        |   Gnu low-level layer          |
        +--------------------------------+
        |   Pthreads Layer               |
        +--------------------------------+
        |       OS                       |
        +--------------------------------+
        |     Machine                    |
        +--------------------------------+

I talk too much, I better shut up.
bye,
Nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server 
application for Nucleic acid and protein sequence search and analysis.
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE, MSCS, MSCE, FM (and Karpov is my chess hero! ..).

Re: Asynchronous IO

[Jon S Anthony]

In article <nh91dnl0a6.fsf@paralysys> nasser@apldbio.com (Nasser Abbasi) writes:

> It seems to me that neither Ada nor any other langauge for that matter 
> can specify what happens when 2 or more tasks/threads attempt 
> access to a shared external system resource such as a file since this 
> by its nature, is the resposibility of the operating system (in
[or runtime kernal for bare HW]

[various good stuff...]

> The behviour should be no different from if 2 or more processes
[or OS threads]
> on the system try to access the same file. The IO operations


> I can be competely wrong here becuase I have not also check the RM on
> this, but I can bet my house that I have not bought yet that this is
> how things would work, and if they don't work like this, then they are

I believe your house is safe! :-)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com