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,b4731a3b5d591abd X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Task Discriminants & Arrays Date: 1997/05/13 Message-ID: #1/1 X-Deja-AN: 241291130 References: <33787506.41C67EA6@spam.innocon.com> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: In article <33787506.41C67EA6@spam.innocon.com>, Jeff Carter wrote: >As I understand it, task discriminants were intended to eliminate the >"serial bottleneck" that results from having to call an initialization >entry to provide information like this to task instances. However, as >far as I can tell, it simply complicates matters: You have to declare an >access type designating the task type, make your array type an array of >these access types, then allocate the tasks at runtime: Yeah, I thought of the heap-based solution, but was trying to avoid using an allocator. Perhaps you just have to do that. >The use of discriminants may be more efficient and have less of a serial >bottleneck. I'd be interested to know if this is the case, and if so, >how much of an improvement one gains with various compilers. I think it's true that more entries mean more overhead, because the run-time executive must monitor activity on each entry queue. In the case of an Initialization entry, it means a loss of efficiency because that entry will never get called more than once. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271