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,67c50b972ca3b532 X-Google-Attributes: gid103376,public From: lph@sei.cmu.edu (Larry Howard) Subject: Re: Realtime Ada Conferences Date: 1996/03/27 Message-ID: <4jadve$pcq@news.sei.cmu.edu>#1/1 X-Deja-AN: 144408002 references: <4j9j9f$620@hacgate2.hac.com> organization: Software Engineering Institute newsgroups: comp.lang.ada Date: 1996-03-27T00:00:00+00:00 List-Id: In article <4j9j9f$620@hacgate2.hac.com> jts@ipld01.hac.com (Jeff T. Stevenson) writes: >Is anything being done to allow Ada compiler vendors to >produce compilers that have task context switch times >in the 20 us range? It seems that most compiler vendors >are not able to comply with the Ada83 tasking model >and provide realtime context switching capabilities. Yes, they're called faster computers. :-) Seriously, the implication I got from what you said is that Ada compilation systems without 20 usec context switching times do not provide realtime context switching capabilities. Many realtime applications do not require this level of performance and are nonetheless realtime. "Realtime" implies to me predictable timing behavior, and not some arbitrary level of performance. >Ada 95 does not really solve the realtime problem because >vendors are not forced to deliver the Ada 95 realtime >extensions. That vendors aren't forced to deliver an annex is precisely the idea of annexes. It's their targeted marketplace that should determine whether a vendor supplies a given annex and at what level of performance. Besides, I'm only familiar with one hard performance requirement in the Real-Time Systems Annex, and that is for clock resolution, which incidentally is 20 usecs or better. This certainly stands to affect task periodicities, but not context switching times. Am I missing something? -- Larry Howard Software Engineering Institute, Carnegie Mellon University lph@sei.cmu.edu (NeXT Mail OK) (412) 268-6397