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,5f0b2f174ad085de X-Google-Attributes: gid103376,public From: Niklas Holsti Subject: Re: tasking in Ada and Annex D question Date: 1999/02/02 Message-ID: <36B77471.ACD2DE1A@icon.fi>#1/1 X-Deja-AN: 439911657 Content-Transfer-Encoding: 7bit References: <793jl9$hf@drn.newsguy.com> <796jj7$5s2$1@pegasus.csx.cam.ac.uk> <796v4e$16e$1@nnrp1.dejanews.com> <797m6h$73g$2@pegasus.csx.cam.ac.uk> Content-Type: text/plain; charset=us-ascii X-Trace: read1.inet.fi 917991123 194.252.1.107 (Tue, 02 Feb 1999 23:32:03 EET DST) Organization: Space Systems Finland Ltd MIME-Version: 1.0 NNTP-Posting-Date: Tue, 02 Feb 1999 23:32:03 EET DST Newsgroups: comp.lang.ada Date: 1999-02-02T00:00:00+00:00 List-Id: Markus Kuhn wrote: > > In robert_dewar@my-dejanews.com writes: > |> The FSU threads need supporting for at least a while for > |> two reasons: > |> > |> [...] > |> 2. They may well be far more efficient, that is true on > |> many targets, did you experiment with this aspect. A lot > |> of people do not need concurrency with system calls (indeed > |> a properly written portable Ada program cannot rely on > |> such concurrency, since it is not guaranteed by the Ada > |> standard), and if FSU threads are more efficient, they > |> may be preferable for many real applications. > > What I have a bit of a problem to understand is, for what > else apart from preemptive scheduling, concurrency when system > calls block, and utilization of multiprocessor systems do I > need tasks for (i.e., all the things FSU doesn't do)? You need tasks to modularise your program's NON-synchronised (i.e. logically concurrent) functions, while programming each such function in an easy-to-understand sequential manner. I do agree that for most Linux applications I can imagine, barring really embedded stuff, the properties of native Linux threads seem more suitable, especially for the system calls. > I realize > that tasks were the only real synchronization mechanism in Ada83, For me the chief attribute of tasks is that they are logically concurrent, not that they occasionally synchronise. > but we now have protected objects to do this more efficiently > without context switches. So I believe that in Ada95, the > concurrency of tasks is much more important than the performance > of task switches, IMHO this was also the case in Ada 83 and all other multi-tasking systems, too. I don't have an opinion on which threads package to adopt for GNAT on Linux, but wanted to butt in with the above. - Niklas