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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/14 Message-ID: #1/1 X-Deja-AN: 646160238 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <2LS85.6100$7%3.493920@news.flash.net> <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> <_dS95.9945$7%3.666180@news.flash.net> <396C9C7F.D9B20E5F@baesystems.com> <396DA53D.19DDBACE@baesystems.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 963542165 216.215.65.127 (Thu, 13 Jul 2000 21:36:05 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 13 Jul 2000 21:36:05 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-14T00:00:00+00:00 List-Id: "David Gillon" wrote in message news:396DA53D.19DDBACE@baesystems.com... > > > David Gillon wrote: > > > One thing I'm still waiting to hear in this discussion is how Eiffel > > would handle a temporal constraint of the type 'Signal A will be updated > > with its new value within 2.5 ms of a change to any of its source > > inputs'. > > Blast, I meant to ask how DBC would handle than kind of constraint, not > Eiffel specifically. Well, it depends upon whether you mean "handle" in a run-time sense, or "handle" in an analytical sense. The particular description you gave could be interpreted as a thread-level constraint, not a module-level constraint (if "source input" means a system input, not a module input). Thread-level analysis tend to be the more interesting ones, so I'm assuming this is what you meant. There are certainly analysis techniques to do this, from which you can derive module-level maximum run-times. (Of course, these run-times will have to be the worst-case, unless the module has some way to know in what thread it is currently participating.) You could then use these module-level constraints in future thread-level analyses. Coding these into the module as a run-time check might be tricky, since you probably want only the time the module is actually running, not the time between the start and end, but it's possible. There are some likely adverse effects of doing so, such as reusability. Assuming you use some standard scheduling technique (RMS, EDF) to enforce the assumptions of your thread-level analysis, you can alternately have your scheduler detect violations of that analysis at run-time. As a practical matter, it's probably much preferable to do the temporal run-time checks in the scheduler.