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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,af960bc705aaf51b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-03 11:50:30 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Complexity of protected objects Date: 3 Mar 2002 11:50:30 -0800 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0203031150.6c62b227@posting.google.com> References: <5ee5b646.0203021711.2c64c56d@posting.google.com> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1015185030 15420 127.0.0.1 (3 Mar 2002 19:50:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 3 Mar 2002 19:50:30 GMT Xref: archiver1.google.com comp.lang.ada:20733 Date: 2002-03-03T19:50:30+00:00 List-Id: Dale Stanbrough wrote in message news:... > Robert Dewar wrote: > > > Remember that the key point about protected objects is > > the ceiling priority protocol, which ensures that > > higher priority tasks can still freely interrupt the > > lower priority tasks inside a PO with a lower CP. > > Just to clarify - the sentence above seems to imply that > a low priority task inside a PO can be forceably removed > from the PO by a higher priority task that want the > -same- PO. Of course not. It seems that you are not understanding ceiling priority protocol at all here. The lower priority task entering the PO immediately raises the priority to the ceiling priority of that PO. The only interruption allowed is by a higher priority task, i.e. whose priority is, as in my message, higher priority than the ceiling priority of the PO. But such a task is not allowed to enter that PO (since you cannot call a PO if your priority is higher than the ceiling priority). This is absolutely fundamental to the operation of protected objects. It also depends on run-till-blocked semantics as required by Annex D, since you also cannot time slice to an equal priority task if you are relying on a lock-less implementation of PO's. In fact most implementations do use locks and all these considerations, including the worrying about PB operations are irrelevant. > Ceiling priority protocal > allows the high priority task to ensure it will be the > task to get access to the PO, and to ensure that low > priority tasks "hurry up and get out of the way" when > working inside a PO. Ah, I think I know your confusion, the above para makes zero sense, but if you replace "Ceiling priority protocol" by "Priority inheritance" it does make sense. I think you are mixing up these two concepts. > On the other hand if the higher priority task is > resources other than the PO used by the low priority > tasks, then I agree. Well in that case you agree, because the ONLY time that a task inside a PO can be preempted is by a task which by definition cannot use the PO! > Another name for POs/semaphores are "bottlenecks". If you > want to increase the natural parallelism of a program, > you should make the code inside them as short as > possible. Nope! That's much too crude a rule. The issue is contention and minimizing context switching time. The two things necessary for meeting strict performance criteria in a hard real time application are a) ensuring that high priority tasks that need immediate control get immediate control (more properly, analyzing carefully the maximum latency) b) minimizing unnecessary context switching to decrease overall system overhead Keeping code in PO's short is neither necessary nor sufficient to ensure that these goals are met. Suppose you have three tasks in the system, two tasks at low priority, and one at high priority. The low priority tasks have no specific deadlines, but they have a lot of computing to do, and it is important to minimize system overhead. The high priority task must always be able to immediately preempt. Assume only one processor. Assume we have a PO shared between the low priority tasks, i.e. its ceiling priority is greater than or equal to that of the low priority tasks, but lower than the high priority task. In this situation the PO *can not* be a bottleneck, and there is absolutely no loss from putting as much processing as you like in the PO, providing you avoid blocking. The bottom line in the design of real time systems is that you have to control the entire behavior of the system, and do a proper analysis. Trying to replace this with simplistic rules is not a good idea. I always like the results of RMA, because they are such a good antidote to the myth of "obvious common sense" (it is so obvious that more urgent tasks be given higher priority, right? :-)