Ada and Unix--Blocked Tasks

Ada and Unix--Blocked Tasks

[Dave Lewicki]

  I have run up against a problem:      

  I am working on a program with multiple tasks, one of which makes
  a call on the Unix "accept()" routine for sockets.  As expected,
  the task blocks and waits for a connection.  

  But, what I didn't expect is that the other tasks all block too and 
  the Ada kernel then goes on to complain about deadlock.  It seems that
  all the tasks are of the same process, so when one blocks, they all
  do.  The only workaround that I can figure is to poll a non-blocking
  "accept()" every 5 seconds or so (yecch).

  Is this a vendor specific problem, or do all Ada/Unix kernals work
  this way?  I am using the Verdix compiler running on Ultrix.

  Has anyone else found any better workaround?  

  Thanks in advance..........

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Dave Lewicki            |    "C++ has a host of operators that will
-- lewicki@beach.csulb.edu |      be explained if and where needed."
-- C.S.U. Long Beach       |         -- _The C++ Programming Language_.
-----------------------------------------------------------------------

Re: Ada and Unix--Blocked Tasks

[Dennis Doubleday]

You can use the fcntl(2) call to make the socket raise a SIGIO signal
whenever data arrives at the socket. Handle SIGIO with a task entry
call and then do the accept.

Dennis Doubleday  (dd@sei.cmu.edu)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213  (412)268-5873

Re: Ada and Unix--Blocked Tasks

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.u]

   The methods indicated here seem kind-of wierd to me.  After all,
an Ada task is SUPPOSED to be an independent thread-of-control.
And when I do something in Ada, I expect the run-time to arange to leave
my other tasks alone, and only block the one needing the service.

   Now I understand that IF I import some non-Ada, specialized-system
stuff into my Ada task, when I call it, it might have loads to do,
and block till done.  But that's what tasks are for!

   Doing the system-specific, unix-style signals seems to me to
be at odds with doing things in Ada with tasks, yes?

   But then my first two experiences with Ada were with the
Honeywell GCOS6 and GCOS8 systems.  In the first, commands
were normally done as tasks (as in Unix), and the Ada compiler
and run-time adopted to OS mechanism to give the natural Ada
parallelism by spawning an OS task whenever Ada would spawn
an Ada task.  And in GOCS8, they used the batch/tss subtask
mechanism to accomplish the same results.  Thus Ada tasks acted
as they should, like real tasks.

   Which leads us to the basic question:

     If the Ada system you are using can't do tasking "correctly"
(i.e., in a non-blocking way) in its implementation, what is in
error?

   Is it the OS (unix in this case)?
   Your Ada compiler vendor (Don't know who)?
   Your Ada run-time vendor?
   Or something else?

   Yours, ...Paul



  
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112-3739
                             [1]-(612) 482-7467

Re: Ada and Unix--Blocked Tasks

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.e]

In article <1991Aug2.181729.28061@sctc.com>, stachour@sctc.com (Paul Stachour)
writes:

>        [some stuff deleted]
>    Doing the system-specific, unix-style signals seems to me to
> be at odds with doing things in Ada with tasks, yes?
> 
>    Which leads us to the basic question:
> 
>      If the Ada system you are using can't do tasking "correctly"
> (i.e., in a non-blocking way) in its implementation, what is in
> error?
> 
>    Is it the OS (unix in this case)?
>    Your Ada compiler vendor (Don't know who)?
>    Your Ada run-time vendor?
>    Or something else?

Questions of this nature (or rather, the nature of the ORIGINAL question)
always make me make the "system-specific knowledge" lecture to my students. 
I'm often asked things like "how does Ada do print spooling" or "how does Ada
handle VT100-style screen control (or mouse movement, etc.)".

I think it's important for designers & programmers of ANY language to remember
what capabilities are controlled by language constructs, and either 
(a) confine the solution to the "domain" of the language capability, or 
(b) realize what portions of the solution are affected by "external controls"
(relative to the language and it's run-time specific support) and act
(implement) accordingly.

Paul's questions are logical ones when trying to DETERMINE the domain of the
implementation "problem", but we as software engineers should attempt to be as
knowledgeable as possible regarding BOTH the language and the environment so
that lengthy problem research/determination is avoided.

Ray
-----
Ray Harwood           |Data Basix           |Associate Faculty,    
Voice: (602)721-1988  |PO Box 18324         |   Pima Community College
FAX:   (602)721-7240  |Tucson, AZ 85731     |Instructor in Ada and Pascal
CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu

Re: Ada and Unix--Blocked Tasks

[Paul Stachour]

>I think it's important for designers & programmers of ANY language to remember
>what capabilities are controlled by language constructs, and either 
>(a) confine the solution to the "domain" of the language capability, or 
>(b) realize what portions of the solution are affected by "external controls"
>(relative to the language and it's run-time specific support) and act
>(implement) accordingly.

>Paul's questions are logical ones when trying to DETERMINE the domain of the
>implementation "problem", but we as software engineers should attempt to be as
>knowledgeable as possible regarding BOTH the language and the environment so
>that lengthy problem research/determination is avoided.

Thanks, Ray.  Indeed that was part of my question:

    What functions/features can we expect in an language, and
    what functions/features are deterimined by the environment,
       and not the language?

    Now, signals are part of unix, so I should expect that if
I write a an Ada program that uses signals that it will not be
portatable to another operating system, say VMS, or if I use
a VMS feature, it will not be portable to MS-DOS or unix or ...

    But tasking IS a part of Ada.  I should be able to expect
that any environment that that supports Ada, should be able to
support tasks.  Furthermore, that if I do ANYTHING in that task
(including a call on an OS-specific function) that could block,
that my task might block.  But I should be able to expect that
the other tasks DO NOT BLOCK just because the OS decides to block
one of the tasks.

    I would maintain that the designer/implementor of the Ada
compiler/run-time combination blew it; they got tasks "wrong".
I would maintain that the only time that they are allowed to
take the one-block-blocks-all behaviour is ONLY if they have
provided a copiler-option for that particular feature.  The general
form of the option is called "Not full language, feature xxxx",
and means:

    I, as the designer and builder of this program, declare to you,
to compilation system, that I do not plan to take advantage of
feature "xxxxx" in my programs.  If you, the compilation system,
can thus give me a more efficient program, I hereby request you
to do so.

    In the absense of such an option, it is my opinion that the
implmetor of the Ada compilation/run-time did it "wrong".  The
fact that it was done this was to get "reasonable efficiency"
on a particular operation system is no excuse.  ..Paul

-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112-3739
                             [1]-(612) 482-7467

Re: Ada and Unix--Blocked Tasks

[Fred Stluka]

In article <1991Jul30.193558.9118@beach.csulb.edu> lewicki@beach.csulb.edu (Dav
e Lewicki) writes:
> 
>   I have run up against a problem:      
> 
>   I am working on a program with multiple tasks, one of which makes
>   a call on the Unix "accept()" routine for sockets.  As expected,
>   the task blocks and waits for a connection.  
> 
>   But, what I didn't expect is that the other tasks all block too and 
>   the Ada kernel then goes on to complain about deadlock.  It seems that
>   all the tasks are of the same process, so when one blocks, they all
>   do.  The only workaround that I can figure is to poll a non-blocking
>   "accept()" every 5 seconds or so (yecch).
> 
>   Is this a vendor specific problem, or do all Ada/Unix kernals work
>   this way?  I am using the Verdix compiler running on Ultrix.

Just as an additional point of data...

VAX Ada on VMS has a similar problem.  All tasks of an Ada program
run in the same process.  When a call to a system service causes the 
process to be blocked, then all tasks are blocked.  For this reason,
DEC provides a package called TASKING_SERVICES which provides access
to the same system services in a mode where only the calling task is
blocked.  This was easy for them to do because the VMS system services 
have 2 modes, blocking and non-blocking, and the non-blocking mode can 
be directed to generate an interrupt when it completes.  No polling is
required.

Non-portable, but it works.
--Fred
-- 
Fred Stluka                               Internet: stluka@software.org
Software Productivity Consortium          UUNet:    ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA   Voice:    (703)742-7236

Re: Ada and Unix--Blocked Tasks

[David Emery]

There is clearly a problem with Unix here, and not with the Ada
implementation.  Unix semantics are pretty clear, the _process_
blocks.  The Unix kernal has no knowledge of Ada tasks, and if all of
the tasks are in a single Unix process, then Unix blocks the process
and all of its tasks.  

There are some hacks (such as using the SIGIO signals) for resolving
this problem, but the basic problem is that Unix was not designed for
multithreaded processes.  This is NOT fixed in POSIX 1003.1, but may
well be fixed (for Ada) by POSIX 1003.4a, which extends the POSIX
interface to handle multiple threads.

				dave emery

Re: Ada and Unix--Blocked Tasks

[EDWARD CRAGG]

> 
> From:cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.
umn.edu!sctc.com!stachour@ucbvax.Berkeley.EDU
> (Paul Stachour) 
> Subject: Re: Ada and Unix--Blocked Tasks
> Message-ID: <1991Aug2.181729.28061@sctc.com>
>
     [stuff deleted]
> 
>    The methods indicated here seem kind-of wierd to me.  After all,
> an Ada task is SUPPOSED to be an independent thread-of-control.
> And when I do something in Ada, I expect the run-time to arange to leave
> my other tasks alone, and only block the one needing the service.
> 
     [stuff deleted]
> 
>    Which leads us to the basic question:
> 
>      If the Ada system you are using can't do tasking "correctly"
> (i.e., in a non-blocking way) in its implementation, what is in
> error?
> 
>    Is it the OS (unix in this case)?
>    Your Ada compiler vendor (Don't know who)?
>    Your Ada run-time vendor?
>    Or something else?
> 
>    Yours, ...Paul
> 

    Paul,
          The factor which you are leaving out of your analysis is 
that Ada was designed for Embedded Systems using specialized 
computers (the ones I am most familiar with are the Navy's UYK-43 and 
UYK-44).  On these systems Ada tasking works "correctly" and is 
reasonably portable between systems.  The reason this that the Ada 
run-time *IS* the machine's OS.  (That incidently is one of the 
reasons that the ALS/N seems so expensive, in addition to developing
an Ada compiler, etc,  They also must develop two fourth generation
operating systems which will run on second generation architectures :-( 
On all other systems with which I am familiar you end up in a finger 
pointing exercise between the OS and the Ada Runtime and the blame 
gets spread around.

ed

 ............................................................
Edward E Cragg                Bitnet:   ECRAGG@GMUVAX
                              Internet: ECRAGG@GMUVAX.GMU.EDU

Re: Ada and Unix--Blocked Tasks

[Howard E. Turner, Jr.]

	stachour@sctc.com (Paul Stachour) writes:

        [ lots deleted HET]

	    But tasking IS a part of Ada.  I should be able to expect
	that any environment that that supports Ada, should be able to
	support tasks.  Furthermore, that if I do ANYTHING in that task
	(including a call on an OS-specific function) that could block,
	that my task might block.  But I should be able to expect that
	the other tasks DO NOT BLOCK just because the OS decides to block
	one of the tasks.

        [ lots deleted HET]

I think the key phrase here is "..I do ANYTHING in that task
(including a call on an OS-specific function) that could block,...".  If
the compiler vendor provided you with an interface to an OS-specific
function, then I would agree with your expectations, however, if you
call an OS function that blocks (implying the entire process), then
I would disagree with your expectations.  When you go outside the bounds
of the language, e.g pragma interface, to get to another language, you
must handle anything that arises.  This includes signals, blocking I/O, etc.

	"Tasking IS a part of Ada."  But it is not a part of the
OS (usually).  The OS (except for maybe Rational's) has no notion 
of Ada tasking, so why would you expect it not to block the entire process?
In particular, Ada tasking is not a part of either VMS or Unix.  Neither
OS will recognize the difference between an executable generated from C or 
Ada or any other language.  Why would you expect the OS to handle executables
derived from Ada source any differently than from C?

Normally, compiler vendors provide a package(s) that support task 
blocking system calls instead of process blocking system calls.  These
are provided in addition to the the process blocking calls, which are
sometimes used.

Howard Turner
howard@esosun.css.gov
619.458.2654
SAIC   San Diego, CA USA

Re: Ada and Unix--Blocked Tasks

[Mike Feldman]

In article <780@esosun.UUCP> howard@hulder.css.gov (Howard Turner) writes:
>
> [stuff deleted]
>
>	"Tasking IS a part of Ada."  But it is not a part of the
>OS (usually).  The OS (except for maybe Rational's) has no notion 
>of Ada tasking, so why would you expect it not to block the entire process?
>In particular, Ada tasking is not a part of either VMS or Unix.  Neither
>OS will recognize the difference between an executable generated from C or 
>Ada or any other language.  Why would you expect the OS to handle executables
>derived from Ada source any differently than from C?
>
> [more stuff deleted]
>
What Paul might be getting at is the notion that an Ada compiler could
(should) map each Ada task onto an OS-level process. I see no reason in
principle why this could not be done; indeed, I think there may be vendors
who are doing it in Unix (can anyone confirm this?). I believe I heard
that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
tasks (can anyone confirm?). In practice, I imagine that vendors are
keeping an ada program - tasks and all - in one OS-level process for
efficiency, reasoning that mapping tasks onto processes is overkill.

This is an area where I'd love to see some material that would let us in
on some of the "inside" discussions that must have taken place over the
years. Norm Cohen? Tucker Taft? Bob Eachus? How did the designers 
imagine the (possible) relationship(s) between tasks and processes?

Mike

Re: Ada and Unix--Blocked Tasks

[Jim Showalter]

Rational's cross-compilers to UNIX boxes have non-blocking I/O.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: Ada and Unix--Blocked Tasks

[Arthur Evans]

Mike Feldman (mfeldman@june.cs.washington.edu) suggests that Ada tasks
might be mapped onto OS processes.

It's a good idea if it can be done.  However, Ada's semantics permits
tasks to share data, and doing so pretty much requires that tasks have
access to shared parts of main memory.  If the OS does not provide this
feature, then this approach fails.  A few OSs, such as Multics, provide
this feature.  I do not believe that Unix does.

The Ada 9X Requirements in Chapter 8 (Distributed Processing) address
the possibility of parts of Ada programs executing on different
processing systems.  Thus it seems likely that 9X will permit this
approach, if the program is structured appropriately.

Art Evans
Ada Consultant
412-963-0839

Re: Ada and Unix--Blocked Tasks

[mcsun!corton!chorus!nocturne.chorus.fr!jloup]

Mike Feldman writes in answer to messages by Paul Stachour and Howard
Turner:

| What Paul might be getting at is the notion that an Ada compiler could
| (should) map each Ada task onto an OS-level process. I see no reason in
| principle why this could not be done; indeed, I think there may be vendors
| who are doing it in Unix (can anyone confirm this?). I believe I heard
| that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
| tasks (can anyone confirm?). In practice, I imagine that vendors are
| keeping an ada program - tasks and all - in one OS-level process for
| efficiency, reasoning that mapping tasks onto processes is overkill.
| 
| This is an area where I'd love to see some material that would let us in
| on some of the "inside" discussions that must have taken place over the
| years. Norm Cohen? Tucker Taft? Bob Eachus? How did the designers 
| imagine the (possible) relationship(s) between tasks and processes?

I was one of the designers of several Alsys Ada compilers. The main
reason we chose to map all tasks in a single Unix process is that Ada
requires all tasks to share memory (unless you put severe restrictions
on the program structure). At the time of the design, it was not
possible to share memory between different Unix processes. On systems
which do allow sharing of memory between OS-level tasks (MVS, LynxOS, VRTX)
the Alsys compilers support a one-to-one mapping between Ada tasks and
OS-level tasks. The MVS compiler even supports a more general M-to-N
model were there can be several Ada tasks per OS-level task and
several OS-tasks per Ada program. The main motivation for this general
model is that tasks switches performed by the Ada runtime without
OS intervention are far more efficient than those requiring system
calls. The user can then tune the program by chosing the best
mapping between Ada tasks and OS tasks. The mapping can be performed
at bind time and does not require recompilation.

There is a little cost for this generality: the M-to-N model is more
complex than the one-to-one model. However the runtime overhead is quite
small and even negligible on systems such as VMS where any system call
costs several thousands instructions.

In the all-to-one model used for Unix, the Ada runtime avoids blocking the
whole process when one Ada tasks makes a blocking IO call, but only
when the predefined IO packages are used. As mentionned by Howard Turner,
the Ada runtime has no control on arbitrary blocking system calls.

To answer your specific comment: there are applications where mapping
Ada tasks onto OS tasks is not overkill but necessary to avoid
blocking the entire Ada program. The M-to-N model lets the user pay
the associated cost only when strictly necessary. On real time systems
such as Chorus where a switch between OS tasks is very efficient, the
simpler one-to-one model is also a sensible solution.

Jean-loup Gailly

Chorus systemes, 6 av G. Eiffel, 78182 St-Quentin-en-Yvelines-Cedex, France
email: jloup@chorus.fr    Tel: +33 (1) 30 64 82 79 Fax: +33 (1) 30 57 00 66

Re: Ada and Unix--Blocked Tasks

[Dan L. Pierson]

Regarding Re: Ada and Unix--Blocked Tasks; mfeldman@june.cs.washington.edu (Mik
e Feldman) adds:

> What Paul might be getting at is the notion that an Ada compiler could
> (should) map each Ada task onto an OS-level process. I see no reason in
> principle why this could not be done; indeed, I think there may be vendors
> who are doing it in Unix (can anyone confirm this?). 

If you refer back to Jerry Callen's posting of a few days ago you'll
see that we do, indeed, do this.  At the minimum, it requires a Unix
extended with shared memory.  This leaves with traditional heavyweight
Unix processes and very slow task creation and switching times.  It
also causes some I/O problems because file descriptors cannot be
shared under normal Unix+shared memory.

The next step on the parallel road is to use a Unix with lightweight
parallel processes such as Mach threads (yes, I know that Mach isn't
really Unix but it doesn't matter) or our UMAXV's variable weight
processes.  Now thread creation is much faster and switching times are
also better.  The I/O problem is solved.  But rondevous (sp?) will
still be slower than a single process implementation and the max OS
thread/process limit will bite some programs.

So the next step is to multiplex Ada tasks as very lightwight entities
on lightweight threads.  I don't know of anyone who's released this
yet. 

All of the above works fine for people who want to use tasks for
parallel computation.  Unfortunately there is another group.  Folks
from a Cedar, Modula-2, etc. background like to use tasks as
programming abstractions to deal with such things as blocking IO.
Some of these people write programs that create *many* tasks; they
don't really want them to all try and run in parallel.  They would
really rather have Ada use a serial lightweight process mechanism like
Sun's.

Since Ada doesn't know about different types of tasks, what should a
poor vendor do?
--

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com

Re: Ada and Unix--Blocked Tasks

[Drew Johnson]

>In article <1991Aug6.040550.785@beaver.cs.washington.edu> mfeldman@june.cs.was
hington.edu (Mike Feldman) writes:
>>In article <780@esosun.UUCP> howard@hulder.css.gov (Howard Turner) writes:
>>>
>>> [stuff deleted]
>>>
>>>	"Tasking IS a part of Ada."  But it is not a part of the
>>>OS (usually).  The OS (except for maybe Rational's) has no notion 
>>>of Ada tasking, so why would you expect it not to block the entire process?
>>>In particular, Ada tasking is not a part of either VMS or Unix.  Neither
>>>OS will recognize the difference between an executable generated from C or 
>>>Ada or any other language.  Why would you expect the OS to handle executable
s
>>>derived from Ada source any differently than from C?
>>>
>>> [more stuff deleted]
>>>
>>What Paul might be getting at is the notion that an Ada compiler could
>>(should) map each Ada task onto an OS-level process. I see no reason in
>>principle why this could not be done; indeed, I think there may be vendors
>>who are doing it in Unix (can anyone confirm this?). I believe I heard
>>that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
>>tasks (can anyone confirm?). In practice, I imagine that vendors are
>>keeping an ada program - tasks and all - in one OS-level process for
>>efficiency, reasoning that mapping tasks onto processes is overkill.
>>
>>This is an area where I'd love to see some material that would let us in
>>on some of the "inside" discussions that must have taken place over the
>>years. Norm Cohen? Tucker Taft? Bob Eachus? How did the designers 
>>imagine the (possible) relationship(s) between tasks and processes?

I believe that Alsys allows you to specify that a task run as a separate
process under Unix -- I do not know what restrictions apply however.
There are 2 main problems with mapping tasks to processes under Unix:
rendezvous and data-sharing.  The performance cost of implementing these
features is very high.  Rendezvous is basically just a time sink, but
shared-data is a time and space sink.  For shared data, there would be only
3 ways that I can think of to implement it:

  1) allocate a shared memory segment to store all global data -- this works
     for static objects, but under Unix, shared memory segments are of fixed
     size.  Dynamic allocations would be very hard to manage.  This gets very
     ugly when you have alot of Ada programs running at once.  Access to all
     of the data in this area would have to be protected as well -- a
     significant performance hit.

  2) Use memory-mapped files -- this has the same drawbacks as (1).

  3) Generate some sort of IPC calls to a kernel-like process managing all
     shared data -- this one is too ugly to even think about :).

What is really needed is a solid, complete thread implementation.  I understand
that Mach has or will have this, and some Unix vendors are slowly migrating
toward this.  Full thread support would mean that most system calls would
block a thread within a process, not the entire process.  Then Ada vendors
can map Ada tasks to threads and everyone is happy.

As for non-blocking IO, there is no LRM requirement that text_io.get cause
a task to suspend until the get can complete.  Unless pre-empted by a higher
priority task, this task should be allowed to run until it either terminates
or suspends due to an entry call, an accept, a delay, etc.  It is perfectly
legal to function in this matter.  Now I agree that there is often a big
difference between what is technically legal and what the customer
wants/expects.  However, in order to implement non-blocking IO in Unix, your
process must either catch and handle SIGIO, or it must poll the descriptor.
Polling can be very expensive from an execution standpoint, and can possibly
result in data loss, depending on the IO device driver involved.  Using SIGIO
maintains the efficiency, but since no Unix that I know of guarantees that 
signals are 100% reliable, this might not be desireable for some users.  The
biggest problem with using SIGIO to provide non-blocking text_io is that
many users want to use non-blocking IO for other forms of unix IO (such as
sockets).  Now there is a conflict between the application and the runtime
because both want to monopolize a single resource.  This can be gotten around
by having the vendor provide routines to interface to SIGIO handling, but this
makes code alot less portable.

IMHO, the best solution to this situation is the standardization of package
POSIX_IO.  I believe that this package provides all the necessary functionality
to perform non-blocking IO, and would then be very portable.

Drew Johnson, Product Support
Verdix
drew@verdix.com

Re: Ada and Unix--Blocked Tasks

[David Emery]

In order for non-blocking I/O to work on Unix, several different
'actors' have to cooperate.  First you need a Unix that supports
non-blocking I/O as a concept.  Usually this works by having a system
call that `queues' the operation, and a signal that tells the
application when the I/O is done.  Next you need a device driver that
also plays this game.  Not all device drivers support non-blocking
I/O, even if the operating system provides the facility.  Finally, you
need the Ada runtime to play along, by handling the signal correctly.  

For this reason, it is almost impossible for a compiler vendor to
guarantee non-blocking I/O in all cases.  In particular, the compiler
vendor cannot guarantee that the user`s devices and device drivers
'play along'.  So take any vendor claims that they support
non-blocking I/O on Unix platforms (without specifying additional
requirements on the device drivers, etc.) with a grain of salt.  It's
possible, and it will probably work on "reasonable systems with
reasonable devices", but it's not guaranteed, especially in the face
of third-party I/O devices.

				dave

Re: Ada and Unix--Blocked Tasks

[Mike Murphy]

In article <1991Aug6.040550.785@beaver.cs.washington.edu> mfeldman@june.cs.wash
ington.edu (Mike Feldman) writes:
>What Paul might be getting at is the notion that an Ada compiler could
>(should) map each Ada task onto an OS-level process. I see no reason in
>principle why this could not be done; indeed, I think there may be vendors
>who are doing it in Unix (can anyone confirm this?). I believe I heard
>that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
>tasks (can anyone confirm?). In practice, I imagine that vendors are
>keeping an ada program - tasks and all - in one OS-level process for
>efficiency, reasoning that mapping tasks onto processes is overkill.

Sequent, Encore, and Alliant have Ada runtimes (based on the Verdix 
compiler) that can map tasking into multiple processes on Unix; but in 
each case the Unix is an extended Unix that provides some support for 
doing so.  Also, it is interesting to note that these systems do not 
simply spawn one process per task but instead spawn N processes, and
then switch T tasks between those processes, where T can be > N.
Intermetrics MVS compiler can map Ada tasks to MVS tasks.

Another problem to deal with that has not been mentioned, is that
LRM 9.8(4) suggests that you may have to poll the other processes
in order to determine what tasks to run.

--mike murphy

Re: Ada and Unix--Blocked Tasks

[mcsun!corton!chorus!nocturne.chorus.fr!jloup]

Drew Johnson (drew@verdix.com) writes:

> What is really needed is a solid, complete thread implementation.  I
> understand that Mach has or will have this, and some Unix vendors are
> slowly migrating toward this.

Both Mach and Chorus have had a solid and complete thread implementation
for several years.

> However, in order to implement non-blocking IO in Unix, your
> process must either catch and handle SIGIO, or it must poll the descriptor.
> Polling can be very expensive from an execution standpoint, and can possibly
> result in data loss, depending on the IO device driver involved.

Polling is not that expensive. If a task cannot perform the IO operation
immediately, the Ada runtime gives control to another ready task, so
that the cpu is not wasted. The IO is retried only later.  Various
strategies are possible: retry after a small fixed amount of time or
check also at synchronization points.

> IMHO, the best solution to this situation is the standardization of package
> POSIX_IO.  I believe that this package provides all the necessary
> functionality to perform non-blocking IO, and would then be very portable.

The user then has to care about non-blocking IO. For many applications
it sufficient to let the Ada runtime handle this transparently.

Jean-loup Gailly
jloup@chorus.fr

Re: Ada and Unix--Blocked Tasks

[Bob Kitzberger @midnight]

Many excellent points have been made on this thread in support of
the de facto practice of mapping multiple Ada tasks onto a single
Unix process -- increased efficiency, necessity due to the shared-
memory model of Ada task hierarchies, etc.  Of course, any serious
software system must make numerous tradeoffs, and I believe that we've
made the right ones.  The majority of developers would scream bloody
murder if a rendezvous took as long as a Unix context switch, which
is only one of the implications of a one-to-one mapping of Ada tasks
to Unix processes.

When Unix supports threads/lightweight processes (ref. current POSIX 
work), rest assured that you'll see Ada implementations taking full 
advantage of them.  Ada has just beaten Unix to the punch by five or 
ten years ;-)

As further data points, TeleSoft's MVS development system supports
the ability to map M tasks to N MVS processes.  Our Sun 3 and Sun 4 
development systems map all of the Ada tasks (within a single Ada 
program) onto a single Unix process.  Non-blocking I/O is provided for 
Text_IO.  Other than Text_IO, I recommend using an earlier poster's
fcntl() and SIGIO/Interrupt entry solution.

Thanks for the feedback indicating how strongly people desire a
stronger cooperation between Unix and Ada tasking.  if you have
specific requirements, I suggest that you contact your vendor's
marketing department... we honestly want to develop the tools
that engineers want, rather than take the moral high ground and
put forth edicts about how people must develop systems.

	.Bob.
	Software Engineer, Ada tasking
-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  (619) 457-2700 x163
------------------------------------------------------------------------------
package body Disclaimer is separate;

Re: Ada and Unix--Blocked Tasks

[Robert I. Eachus]

     Since Mike Feldman asked, and since I was involved in the early
years, I'll tell you what I expected at the time.  On systems which
supported sharing of memory between tasks and with relatively low-cost
OS task or process switching, everyone expected Ada tasking to be
mapped to OS tasking, even if entry call parameters had to be copied.
For example, the DPS6 Ada compiler put the parent tasks environment
(and the global heap) in the child's address space.  This meant that a
parameter, such as a record normally passed by reference, needed to be
copied to the global heap if the call was from child to parent.

    On tasking hostile OS's such as OS/370 and the then current
version of VMS, Ada programs were expected to run inside a single OS
process.  Things like MS-DOS (I won't call it an OS then...still might
not now.) had no concept of tasking, so it would all have to be done
in the Ada run-time and the "interesting" question was how close you
could come to doing non-blocking keyboard I/O right.

    Unix was the interesting case.  On some versions it was almost
possible to do it "right," on others clearly impossible.  What I
expected, but never saw, was for vendors to have a single process
which contained all the user written tasks, and hide additional
processes in the vendor supplied IO package bodies.  For example, a
run-time could do its own local buffering and only call (or create)
another process when there was a probability of a long wait.  If done
right, the run-time would figure out when it needed to create another
child process and otherwise pass data to a process on the free list
and wake it up.  Has anyone ever done this?  On current versions of
Unix it should work quite well, and give you the illusion of one
process per task without the process switching overhead.


--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Ada and Unix--Blocked Tasks

[torolab4.vnet.ibm.com!jrussell]

Mike Feldman asks if any vendors map Ada tasks onto OS processes.
The IBM compiler for MVS has a pragma, OS_TASK, that does this for a
task or task type, and some form parameters that control
synchronous/asynchronous I/O.  (This is the same compiler Bob Kitzberger
mentioned.)  People who want to do real-timish things typically use the
pragma, because MVS task scheduling is pretty fair.  There are some
additional hooks into MVS tasking, such as a priority for MVS subtasks
distinct from the Ada priority, and ways to minimize the overhead of OS
task creation/termination.

The same pragma is part of the IBM RISC System/6000 compiler, using
the AIX shared memory features.

The approach does have some possible disadvantages, like more expensive
context switching, but people who need the extra capability are generally
positive.

John
(Representing myself only.)

Re: Ada and Unix--Blocked Tasks

[bu.edu!inmet!offer]

> 
> People who want to do real-timish things typically use the
                        ^^^^^^^^^^^
> pragma, because MVS task scheduling is pretty fair.
                                                ^^^^

???? Could you elaborate please ?

Offer