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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.140.216.6 with SMTP id m6mr3385369qhb.12.1438897430892; Thu, 06 Aug 2015 14:43:50 -0700 (PDT) X-Received: by 10.182.44.163 with SMTP id f3mr23874obm.7.1438897430830; Thu, 06 Aug 2015 14:43:50 -0700 (PDT) Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!69no4281013qgl.1!news-out.google.com!o13ni7876igw.0!nntp.google.com!pg9no7662213igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 6 Aug 2015 14:43:50 -0700 (PDT) In-Reply-To: <14a3a434-73a8-434f-9196-45c46b381e21@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.203.194.21; posting-account=bXcJoAoAAAAWI5APBG37o4XwnD4kTuQQ NNTP-Posting-Host: 74.203.194.21 References: <27492d6c-3bf8-4eb9-8ebb-4d9f621235eb@googlegroups.com> <14a3a434-73a8-434f-9196-45c46b381e21@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <50e2f61b-bdc3-485d-a492-b44bac1f8fc0@googlegroups.com> Subject: Re: Ravenscar and context switching for Cortex-M4 From: Patrick Noffke Injection-Date: Thu, 06 Aug 2015 21:43:50 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:194688 Date: 2015-08-06T14:43:50-07:00 List-Id: On Thursday, August 6, 2015 at 4:05:15 PM UTC-5, Patrick Noffke wrote: > On Monday, February 16, 2015 at 3:28:08 PM UTC-6, Simon Wright wrote: >=20 > > One thing that puzzles me is the locking/unlocking of the entry: this i= s > > done (in that RTS) by raising the caller task's priority to the ceiling > > priority of the task, if necessary. So what about interrupts? And when > > the handler wrapper (you can see this by compiling the package with the > > PO in with -gnatdg) locks the entry, it seems to raise the current > > task's priority, where the current task has nothing to do with the PO a= t > > all! > >=20 >=20 > There is another bug that I've discovered in the GNAT 2015 Ravenscar-full= runtime (Cortex-M4) that appears to be caused by the Interrupt_Wrapper cha= nging the task's priority. When there is no Runnable task, Leave_Kernel wi= ll Insert the non-Runnable task back into the ready queue (with state of De= layed or Suspended). This task is also stored in the Running_Thread_Table = (only one value in the table for a single CPU). Then an interrupt comes al= ong and raises the priority of the Runnable_Thread_Table task (which is Del= ayed) to that of the interrupt. And the task that is woken up by the inter= rupt goes later in the ready queue, since its priority is now lower than th= e Delayed task. >=20 > This ultimately causes the task that was readied by the interrupt to not = run (in my case, it never runs again). I haven't traced all the subsequent= behavior to know exactly why this happens, but if I don't change prioritie= s in the Interrupt_Wrapper, the problem seems to be gone. >=20 > Does anyone have an idea why the task priorities are changed in the Inter= rupt_Wrapper? I'm wondering if I'm introducing a problem that was supposed= to be fixed by not changing the priorities. But as Simon pointed out, the= current running task may have nothing to do with the PO associated with th= e interrupt, so it seems odd to change the priority here. >=20 Not to mention, an interrupt handler (possibly with associated PO) may have= nothing to do with *any* task, much less the current task. A further point of confusion is why Self_Id.In_Interrupt is getting set to = True while executing the user handler. In_Interrupt is used by Current_Int= errupt, which seems related to execution time stuff. I'm not sure if this = is needed (or accurate given the above). Patrick