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,5b0308c42409e5df X-Google-Attributes: gid103376,public From: "R. Tim Coslet" Subject: Re: Protected Objects (Geeenhills & VxWorks) Date: 2000/02/10 Message-ID: <38A33278.423F4DF9@kaisere.com> X-Deja-AN: 584279228 Content-Transfer-Encoding: 7bit References: <38A30F81.F0CAF1E6@kaisere.com> <38A31EF9.ECE0B395@averstar.com> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-la.pbi.net 950219226 206.170.2.191 (Thu, 10 Feb 2000 13:47:06 PST) Organization: SBC Internet Services MIME-Version: 1.0 NNTP-Posting-Date: Thu, 10 Feb 2000 13:47:06 PST Newsgroups: comp.lang.ada Date: 2000-02-10T00:00:00+00:00 List-Id: protected type Example_Protected_Object is entry Send; procedure Signal_Available; procedure Check_For_Timeout; private Available : Boolean := False; I_Am_Tired_Of_Waiting : Boolean := False; Waiting : Boolean := False; end Example_Protected_Object; The procedure Check_For_Timeout is actually getting called from a procedure that is called by another procedure... (nested a few levels deep) inside the main loop (which is in a task scheduled by another interrupt), not the main subprogram. The scheduling logic of the main loop task calls Check_For_Timeout just before making the call to an entry in the task that calls the entry Send, every 3rd time the main loop runs. The intention of the call to Check_For_Timeout is to make sure that that task has gotten out of the Send entry of the protected object, so that it can accept another call and not queue it, if the interrupt is missed (which in this system would indicate a serious hardware malfunction). The main subprogram in this system is only used for initialization. Once that is complete it suspends itself (via a call to VxWorks) and all further processing is done in tasks. BTW, I have to test this by faking in software that the interrupt didn't occur as the hardware always generates it, whether I want it or not :-) Greenhills has been less than helpful on allot of things, and I thought that this was basically an Ada95 usage question... We have almost removed all protected objects and converted to code that directly calls VxWorks (the guy that has been doing this says he would rather just rewrite the ENTIRE program in C, because at least he can tell exactly what the code is doing whereas Ada "does too many things that you have no control over"). This approach bothers me. R. Tim Coslet Tucker Taft wrote: > "R. Tim Coslet" wrote: > > > > We have been having repeated problems where Protected Objects don't seem > > to be functioning correctly in the environment we are working with > > (Greenhills V1.8.9 w/ VxWorks). > > > > The simplest case I have is the following... > > It would help if you included the source for the spec of the protected unit, > and the source for the main subprogram. It is not clear who > sets the value of Waiting. Also, can you be sure that the > main routine is actually calling Check_For_Timeout more than once? > Perhaps you could add some kind of trace calls into these routines > to document the order in which things are being called. > > You should also certainly check with Green Hills. I'm sure > they have a number of customers who are using protected > objects to handle interrupts on VxWorks. > In this case, it seems like the interrupt is irrelevant, since > you claim that you are testing the case when the interrupt does not > occur, and a timeout is supposed to take effect. > > -Tucker Taft stt@averstar.com > > > > protected body Example_Protected_Object is > > > > entry Send when Available or > > I_Am_Tired_Of_Waiting is > > begin > > > > -- Do some things here... > > > > -- reset the barrier flags > > Available := False; > > I_Am_Tired_Of_Waiting := False; > > > > -- reset the waiting flag > > Waiting_For_It := False; > > > > end Send; > > > > procedure Signal_Available is > > begin > > > > -- set the barrier flag to indicate data has been received > > Available := True; > > > > end Signal_Available; > > > > procedure Check_For_Timeout is > > begin > > > > -- set the barrier flag to indicate data has not been received > > I_Am_Tired_Of_Waiting := Waiting; > > > > -- set the waiting flag > > Waiting := True; > > > > end Check_For_Timeout; > > > > end Example_Protected_Object; > > > > The entry (Send) is called from one task, to hold it until data arrives. > > > > The procedure (Available) is called from a task that is triggered by an > > interrupt. > > The procedure (Check_For_Timeout) is called from the main program loop, > > running at a lower priority than the other two tasks. > > > > When everything is working normally, Available is called following the > > interrupt processing and the queued call to Send is released from its > > barrier. Check_For_Timeout is also periodically called by the main > > program and as expected nothing happens. > > > > When I prevent Available from being called however the system locks up. > > This is not what I expected. I expected the call to Check_For_Timeout by > > the main program to release the queued call to Send from its barrier. > > > > Am I using the protected object correctly, or is something broken in the > > Greenhills implementation of protected objects? I strongly suspect > > Greenhills as I have read the LRM sections repeatedly and they seem to > > say this should work and we were previously forced to convert all > > protected object Interrupt Handlers to direct calls to VxWorks services > > (bypassing the Ada implementation). > > > > R. Tim Coslet > > CosletT@KaiserE.com > > -- > -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ > Technical Director, Distributed IT Solutions (www.averstar.com/tools) > AverStar (formerly Intermetrics, Inc.) Burlington, MA USA