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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,216b18d81cce4f75 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-29 08:46:13 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!t-online.de!newscore.gigabell.net!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada Microkernel? Date: Fri, 29 Jun 2001 11:22:38 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9hi6fv$lop$1@nh.pace.co.uk> References: <%3H_6.416$Kf3.3173@www.newsranger.com> <9hfgrm$ngd$1@nh.pace.co.uk> <3B3B6D4C.5DEC7D52@online.no> <9hfv15$s59$1@nh.pace.co.uk> <9hfvo1$sbd$1@nh.pace.co.uk> <9hhv2m$ivm$1@nh.pace.co.uk> <4J0%6.1684$Kf3.17425@www.newsranger.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 993828159 22297 136.170.200.133 (29 Jun 2001 15:22:39 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 29 Jun 2001 15:22:39 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:9259 Date: 2001-06-29T15:22:39+00:00 List-Id: I'm not an expert, nor do I play one on TV, (NDIPOOTV?) but here's why I think there would be a problem with marking a process "Non-Time-Slicing": Suppose you want your process to do a run until blocked kind of thing. Suppose the rest of the world wants to timeslice. The timeslice thing is going to require some sort of setting of a clock/interrupt/timer that will stop your run-until-blocked process to give control to the scheduler. The secheduler may look and say "Ted's job is still the most important thing to do" and give you back the processor, but in the mean time, you've been interrupted and had control given to the OS for some duration. even if the duration is predictable, its still undsirable because it takes time from you and may happen at A Bad Time(tm). What may be a bigger problem is that once that timer goes off and the scheduler gets invoked, you probably aren't going to be able to tell in advance how long its going to be before you get to run again. Non-determinism is definitely A Bad Thing(tm). It for sure would shoot Rate Monotonic right square between the eyes. I'm not sure I could see a way around not having the timer go off at regular intervals unless you came up with some way of masking the interrupts until you got blocked. But having blocked and enabling the interrupts so others could round-robin, you're back with the problem of a non-deterministic delay when you do block. This is *probably* A Bad Thing if you were counting - for example - on your blocking operation taking a fixed & deterministic amount of time so you don't periodically blow your timing budget. I'm *reasonably* persuaded that the only way you could do it would be to say at boot time - or via some privileged command - "I want to operate Realtime" and let the GUI window apps' performance suck in exchange for the guarantees you need from an RTOS. Since people are doing essentially this to get realtime work done under Windows, it would seem like A Good Thing(tm) to build right in from the start. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" wrote in message news:4J0%6.1684$Kf3.17425@www.newsranger.com... > > I was thinking you ought to be able to somehow mark a process as "non > time-slicing" or somesuch so that it could be scheduled along with normal user > processes, but still be realtime. Any real-time process is probably going to be > higher-priority than a user process, but it could still use the same scheduler > this way. But I'm not an expert in this field, so I'm guessing there may be some > instrinsic problems I don't see. >