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: ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) Subject: Re: Ada versus Java - Tasking Date: 1997/01/19 Message-ID: #1/1 X-Deja-AN: 210821687 references: <01bc03ee$594dc520$829d6482@joy.ericsson.se> organization: Telenor Online Public Access newsgroups: comp.lang.ada Date: 1997-01-19T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: In article , Ole-Hjalmar Kristensen FOU.TD/DELAB 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