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.66.164.225 with SMTP id yt1mr3334053pab.32.1438895114147; Thu, 06 Aug 2015 14:05:14 -0700 (PDT) X-Received: by 10.182.92.233 with SMTP id cp9mr23111obb.17.1438895114110; Thu, 06 Aug 2015 14:05:14 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!se8no11231igc.0!news-out.google.com!nt1ni873igb.0!nntp.google.com!se8no11222igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 6 Aug 2015 14:05:13 -0700 (PDT) In-Reply-To: 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <14a3a434-73a8-434f-9196-45c46b381e21@googlegroups.com> Subject: Re: Ravenscar and context switching for Cortex-M4 From: Patrick Noffke Injection-Date: Thu, 06 Aug 2015 21:05:14 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:27380 Date: 2015-08-06T14:05:13-07:00 List-Id: On Monday, February 16, 2015 at 3:28:08 PM UTC-6, Simon Wright wrote: > One thing that puzzles me is the locking/unlocking of the entry: this is > 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 at > all! >=20 There is another bug that I've discovered in the GNAT 2015 Ravenscar-full r= untime (Cortex-M4) that appears to be caused by the Interrupt_Wrapper chang= ing the task's priority. When there is no Runnable task, Leave_Kernel will= Insert the non-Runnable task back into the ready queue (with state of Dela= yed or Suspended). This task is also stored in the Running_Thread_Table (o= nly one value in the table for a single CPU). Then an interrupt comes alon= g and raises the priority of the Runnable_Thread_Table task (which is Delay= ed) to that of the interrupt. And the task that is woken up by the interru= pt goes later in the ready queue, since its priority is now lower than the = Delayed task. This ultimately causes the task that was readied by the interrupt to not ru= n (in my case, it never runs again). I haven't traced all the subsequent b= ehavior to know exactly why this happens, but if I don't change priorities = in the Interrupt_Wrapper, the problem seems to be gone. Does anyone have an idea why the task priorities are changed in the Interru= pt_Wrapper? I'm wondering if I'm introducing a problem that was supposed t= o be fixed by not changing the priorities. But as Simon pointed out, the c= urrent running task may have nothing to do with the PO associated with the = interrupt, so it seems odd to change the priority here. Patrick