Re: Ada versus Java - Tasking

[ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)]

In article <E48D1A.1sL@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

   In article <OHK.97Jan18194202@ultra.tfdt-o.nta.no>,
   Ole-Hjalmar Kristensen FOU.TD/DELAB <ohk@ultra.tfdt-o.nta.no> wrote:
   >These task switching times are still pretty horrible though. Using
   >Unix processes and pipes or System V message queues, you can do just
   >as well. Any idea of why this is so? Does it follow from the
   >definition of an Ada task, or is it just this particular
   >implementation.

   No, it's not hard to make task switching fast, if you're willing to give
   up the idea that every Ada task should map onto exactly one OS
   task/thread.  But there are some advantages to that one-for-one mapping,
   despite the HUGE performance penalty.  E.g., when a task does a blocking
   system call, it's nice if some other task gets to run while it's
   waiting.  Making that happen is hard (but I don't think impossible!)
   unless each Ada task maps to an OS task (thread).  And if the OS threads
   are horribly slow (which is often the case), then tough luck.

   >With a task switching overhead of this magnitude, tasks become
   >unattractive as a way of programs dealing with high-speed IO, for
   >example.

   Indeed.

   - Bob

I think I would be willing to give up the idea that every Ada task
should map onto exactly one OS task/thread. In my (admittedly limited)
experince with POSIX threads, you are not able to get the same amount
of overlapping IO as by using explicit asynchronous read/write
calls. My tests have been limited to SunOS and HP-UX, but I suspect
most other thread implementations will give similar results. A POSIX
thread will be suspended if the device is not ready, ans as you say,
other threads may run while the suspended thread is waiting. However,
my tests indicate that while the (blocking) read/write call is
executed, the whole OS process is suspended. At least, if you have two
threads doing IO on separate devices, you will not get any overlap of
those IO operations. In other words, using a native thread package
does not automagically transform normal blocking read/write calls into
asynchronous calls, which I find quite reasonable.

At best, the native threads give very vague promises about the degree
of real concurrency, so if I have to choose, I would rather have fast
task switching and handle any blocking system calls myself.

The new protected types seem really promising, though.

Ole-Hj. Kristensen