From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7d2c8b4487ef2145
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Ada versus Java - Tasking
Date: 1997/01/19
Message-ID: <E48D1A.1sL@world.std.com>#1/1
X-Deja-AN: 210739492
references: <01bc03ee$594dc520$829d6482@joy.ericsson.se>
 <32DFC320.41C67EA6@innocon.com> <OHK.97Jan18194202@ultra.tfdt-o.nta.no>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1997-01-19T00:00:00+00:00
List-Id: <comp.lang.ada>


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