Ada and Unix Sockets

Ada and Unix Sockets

[Bradley Schmerl]

Greetings,

	I am writing a program in Ada which uses a blend of X events and socket
communication with other ada programs. I am running into a problem doing this,
because when a call is made to wait for a socket (or get the next X Event), the
whole Ada program (only one Unix process) blocks, and so other tasks don't 
continue running. Is there any way of overcoming this problem, apart from using
a busy loop to continually poll for events?

	Oh, I am using Verdix Ada 5.5 on an Encore MultiMax under Unix.

	Could you also e-mail me directly, as I don't read this newsgroup 
often.

Bradley.
--
bradley@cs.adelaide.edu.au

Re: Ada and Unix Sockets

[Paul Stachour]

bradley@chook.adelaide.edu.au (Bradley Schmerl) writes:
>	I am writing a program in Ada which uses a blend of X events
> and socket communication with other ada programs. I am running into
> a problem doing this, because when a call is made to wait for a socket 
> (or get the next X Event), the whole Ada program (only one Unix process) 
> blocks, and so other tasks don't  continue running. Is there any way 
> of overcoming this problem, apart from using
> a busy loop to continually poll for events?
> Could you also e-mail me directly, as I don't read this newsgroup 
>  often.

     This is a rather "standard" problem.  One has to begin by
thinking in a concurrent mode.  We note that many OS'es don't
have tasks (e.g., MSDOS) and others don't have threads(e.g, most unixes).
What you are looking for is an OS that has threads (also-known-as
thin or weak processes) and and Ada Compiler that implements each
task as a thread.

     Any Ada compiler builder has a dilema to overcome, namely:

  "Is an Ada Task a OS Process or not?"

     If the answer is "Yes", i.e., an Ada task is an OS process, then:

         In some OS'es, there is a problem of sharing memory.
         In some OS'es, there is an interrupt handling problem.
         In some OS'es, the context-switch it too long.
         In some OS'es, one can't implement certain rendesvous cheaply.

     If the answer is "No", i.e., a whole Ada program (multiple Ada tasks)
         is one OS process, then:

         In some OS'es, there is a blocking of all tasks when a program
              does IO.
         In some OS'es, there is a blocking of all tasks when a program
              does an OS Service call. 
         In some OS'es, there is a blocking of all tasks when a program
              calls some service subprogram that ... [Your case]

     Let's face it, most interfaces are NOT designed in an asynchronous 
         manner, where one sets-off a request, and then checks-back to
         see if it is done. [The IO requests in IBM's OS/360 and followon
         lines are a good example of doing it "right" from a tasking
         point-of-view, but it is OS/MVT].

     Stepping back a moment, does the Ada compiler vendor have a 
         responsibility to ensure that ALL subroutines you call from
         your Ada program behave responsibly?  No, that responsibility
         is only for TEXT_IO and other native-Ada packages.

     What would I do?  Given that the subroutine is non-Ada (if it is
         Ada then the subroutine implementor has a duty), I would have
         to step-out of Ada and create another OS-process.  I then need
         that OS process to issue the sockets [or whatever] call; thus
         blocking.  And have it send my Ada program a message with the OS
         message service, or use shared memory, or something similar,
         when the service was completed.

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

Ada and OS tasks (was Ada and Unix Sockets)

[Jerry Callen]

In article <1990Nov20.205819.24040@sctc.com> stachour@sctc.com (Paul Stachour) writes:

>[ Interesting article on whether or not Ada runtimes should map Ada tasks
   to underlying OS tasks/thread/processes/etc. ]

I've worked on Ada runtimes that did it both ways. Generally, you have more
flexibility if Ada tasks use the underlying OS tasks, but you pay a price in
overhead; how much depends upon the system.

Paul missed a few issues; here are some more:

- The underlying OS may not provide much, if any, control over task scheduling,
  which renders Ada priorities meaningless.

- The OS may not provide much in the way of locking primitives; building your
  own (with, say test and set and spin locks) may prove problematic. For
  instance, suppose a task holding a lock is blocked by the OS and another
  task tries to get the lock? You can burn a lot of CPU in spin locks.

  This is important because a multi-threaded Ada RTS is going to make
  heavy use of locking.

- How do Text_IO and the other predefined Ada I/O packages behave in the
  presense of tasks? Making them "do the right thing" may entail a lot
  of overhead that most programs don't need. (My vote: control via the
  forms string.)

So how have various Ada implementations done it? Here are a few I am familiar
with; I'd love to see folks post more. I have a lot of IBM/370 experience, which
is reflected in the following list...

- Intermetrics MVS Ada: one Ada task per MVS task. Task create times are
  unpleasantly long, but rendezvous isn't bad; as Paul pointed out, all
  I/O in MVS is inherently asynchronous, so the OS provides reasonably
  efficient "wait/post" primitives. Since MVS runs on multiprocessors, it
  is possible to really have multiple Ada tasks executing simultaneously.
  Shared memory isn't a problem since MVS tasks share an address space.

- Intermetrics CICS Ada: one Ada task per CICS task. I don't have any idea
  how well it performs.

- Telesoft MVS Ada: mapping controlled by pragma; I don't have details. 
  I would expect the performance to be similar to the Intermetrics RTS (at
  least regarding OS task create/rendezvous times).

- current Encore Ada (uses Verdix technology): two schemes available. The
  "sequential" Ada is the usual "one Unix process for the whole program"
  approach, with the Ada RTS handling dispatching. The "parallel" Ada
  allows a variable number of Unix processes to be allocated to a program,
  which the RTS multiplexes among the Ada tasks; it's sort of a hybrid of
  the two usual approaches. Memory is shared via Unix shared memory
  facilities. I/O is funnelled through a single I/O process.

- forthcoming Encore Ada (for Encore 88K based systems): one "very lightweight
  process" (thread, really) per Ada task. All threads share an address space.
  I'm currently working on this implementation; needless to say, it runs like
  a bat outta hell. :-)

-- Jerry Callen
   jcallen@encore.com

Re: Ada and OS tasks

[Jean-Loup Gailly]

In article <13325@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes:

> I've worked on Ada runtimes that did it both ways. Generally, you have more
> flexibility if Ada tasks use the underlying OS tasks, but you pay a price in
> overhead; how much depends upon the system.

Quite correct. I have also worked (within Alsys) on Ada runtimes that
did it both ways. When Ada tasks are mapped to OS threads, the
rendezvous time is usually dominated by the time spent in the OS, even
when the Ada runtime does its best to minimize the number of system
calls.

> - The OS may not provide much in the way of locking primitives; building your
>   own (with, say test and set and spin locks) may prove problematic. For
>   instance, suppose a task holding a lock is blocked by the OS and another
>   task tries to get the lock? You can burn a lot of CPU in spin locks.
> 
>   This is important because a multi-threaded Ada RTS is going to make
>   heavy use of locking.

Yes, spin locks should not be used, but there are other alternatives. You
can build a very fast locking primitive by making an (expensive)
blocking system call only in the case of contention, that is, when a
test-and-set fails. Variants of this scheme are used in the Alsys Ada
runtimes which map tasks onto OS threads, and in the implementation of
mutexes in the Chorus operating system.

> So how have various Ada implementations done it? Here are a few I am
> familiar with; I'd love to see folks post more.

- Alsys MVS Ada: mapping controlled by pragma and binder options. A variable
  number of MVS tasks can be allocated, each running a variable number of
  Ada tasks. So both extremes are possible (all Ada tasks mapped to one
  MVS task, or one Ada task per MVS task).

- Alsys Ada on LynxOS: the current implementation supports only the one to one
  mapping between Ada tasks and LynxOS threads.

- Alsys Ada on VRTX: also one to one mapping.

- Alsys Unix compilers: the usual "one Unix process for the whole program".
  Predefined IO "does the right thing", that is, one task blocked on IO does
  not block other tasks. However non predefined IO (such as sockets) is
  blocking.

				Jean-loup Gailly
E-mail: jloup@chorus.fr		Chorus systemes, 6 avenue Gustave Eiffel
Fax: +33 (1) 30 57 00 66	78182, St-Quentin-en-Yvelines-Cedex
Tel: +33 (1) 30 64 82 79	France

Re: Ada and Unix Sockets

[Dennis Gibbs]

In article <1873@sirius.ucs.adelaide.edu.au>, bradley@chook.adelaide.edu.au (Bradley Schmerl) writes:
> 
> 	I am writing a program in Ada which uses a blend of X events and socket
> communication with other ada programs. I am running into a problem doing this,
> because when a call is made to wait for a socket (or get the next X Event), the
> whole Ada program (only one Unix process) blocks, and so other tasks don't 
> continue running. Is there any way of overcoming this problem, apart from using
> a busy loop to continually poll for events?
> 
> Bradley.
> bradley@cs.adelaide.edu.au


Bradley,

Could you email me the replies you get to your posting to comp.lang.ada regarding
Ada and Unix Sockets?  We are experiencing the same exact problem (Ada tasks get
blocked while waiting for events) and I don't know yet how to solve this either!

Any replies you get that you could send me would be most appreciated...Meanwhile if
I uncover any solutions I'll send them your way....

Thanks!

Dennis Gibbs
TRW Systems Integration Group
(703) 802-1961
...uunet!tfsg!dennis

P.S. I tried email to you but it bounces.....

Re: Ada and Unix Sockets

[Jean-Marc Alliot]

Our news system broke off last week and I didn't get the address of the
poster of the query. So I'm posting this answer directly to the net.

We experiened the same rpoblem using ADA-ALSYS compiler and
UNIX sockets on a SUN (3.5, 4.0 and 4.1 OS). 

The reason is quite easy to understand. Every ADA task belongs to the same 
UNIX process. And any system call (like read, write or accept) is 
blocking (by default), and blocking for the WHOLE UNIX process. So
every task is automatically blocked. Solving completely the problem
was quite difficult. We had to mask the UNIX OS, and it ended in more than
5000 lines of ADA code. The packages are now efficient and probably portable
on any BSD-based system.