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,894846be18e92713 X-Google-Attributes: gid103376,public From: "Theodore E. Dennison" Subject: Re: GNAT R/T Annex and Win95 Date: 1996/04/23 Message-ID: <317D1483.62319AC4@escmail.orl.mmc.com>#1/1 X-Deja-AN: 151015763 references: <96042310111457@psavax.pwfl.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Information Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Date: 1996-04-23T00:00:00+00:00 List-Id: Marin David Condic, 407.796.8997, M/S 731-93 wrote: > > Well, not quite a "straight NT question." It's related to using > Ada & WNT in real-time data acquisition systems. A quality > compiler capable of real-time work may be pathetic in behavior if > the underlying OS doesn't support what you need to do the job. I know where you are comming from here, but if it isn't a "straight NT question", it at least ends up being a straight NT answer. You typically don't want to rely on language facilities like the delay statement (especially the delay statement) in a true real-time environment. You HAVE to use OS calls, which are (mostly) language independent. > >The second is the "Multimedia Timer". This timer allows you to define > >a callback that will get called directly by an interrupt, without any > >message queue processing overhead. The resolution is said to be > >"about 16 (Intel) milliseconds". Whatever that means, you can get the > >exact resolution on your system via a call to "timeGetDevCaps". (Oddly > >enough, Microsoft's example uses a resolution of 5 milliseconds) This > >is a little more useful, but still not what we would like to see. > > > That's useful to know about the clock. Would you happen to know if > this is the mechanism used by GNAT (or other implementations) for > the "delay" statement? I don't happen to know, but I do know enough about NT to tell you that that would be HIGHLY unlikley. I'd expect to see a delay on NT use the SleepEx call to suspend the thread for a given number of milliseconds. You can't really use "delay" for real-time timing anyway (how do you account for processing time between delay statements?) You need something that iterrupts you at a given, reliable interval no matter what other processing you are doing. > I think that one of our biggest concerns is not necessarily clock > resolution, but more one of behavior in a non-dedicated > environment. Some of our systems run stand-alone and in such a > case you can generally make things work because there won't be any > suprises. But in other systems, we may be collecting data in > real-time from an engine test and an operator might be using the It looks like a multimedia timer iterrupt actually puts the rest of the OS on hold to call your interrupt callback (my manual isn't real specific about this). So no matter what priority your process/thread is, your ISR will get called at the specified interval. The manual warns about degragated system performance when using small intervals. The other option, I guess, would be to set up a timer, and jack up the priority of the process that services its message queue to real-time. This solution isn't hard real-time, but does prevent your servicing thread from having the CPU witheld when its needs it. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison |