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,a5681531ca1cf09e X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Tasking performance between Ada83 and Ada95 Date: 1997/06/09 Message-ID: #1/1 X-Deja-AN: 247273127 References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-06-09T00:00:00+00:00 List-Id: Edmond Walsh said <> Of course, the mapping of Ada tasks to Unix threads is certainly a *good thing* if you need to take advantage of the flexibility of this mapping. For example, if you are using one of SGI's high end MP's, then you definitely want this mapping. But there certainly is an efficiency penalty to be paid. Actualy from your post it is not quite clear what exactly you are referring to in "lot of effort" and "underlying problem" here. Were there problems other than efficiency? Sometimes, especially in Ada 83 programs, where the dispatching semantics were not defined, programs make assumptions about the dispatching that are non-portable. This is avoided in Ada 95 if you are using a compiler that implements full Annex D semantics (true of the SGI compiler for example), but that does not necessarily help the porting of legacy code. Robert dewar Ada Core Technologies