Reducing the cost of real-time software through a cyclic task abstraction for Ada

Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Shark8]

Has anybody read the Patrick Bernardi thesis "Reducing the cost of real-time software through a cyclic task abstraction for Ada"?

(See https://openresearch-repository.anu.edu.au/handle/1885/112723 for the PDF.)

It seems really interesting to me, and for what appears to be some relatively minor refinements to the language (via aspects, mainly; only one keyword [which might not be ABSOLUTELY needed]) provides some rather large advances in both usability and analyzability/provability of tasks.

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[guyclaude.burger]

That paper is huge, no wonder no one (seems to) dares to review it. Could you make a summary, or a short exposé on why "loop delay until ..." or similar statements are not enough to implement neatly the desired semantic ?

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Lucretia]

Well, I was going to reply to the deleted message.

I scanned down this massive doc, this looks like a callback mechanism from an anonymous task.

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Shark8]

On Wednesday, February 7, 2018 at 11:25:48 AM UTC-7, Lucretia wrote:
> Well, I was going to reply to the deleted message.

I didn't even see the deleted message.

> 
> I scanned down this massive doc, this looks like a callback mechanism from an anonymous task.

Hm, I don't think that's nearly what's going on here (I've read most of it) because there's refinements which allow better worst-case analysis AND open up the possibility for more varied scheduling in SPARK.

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Lucretia]

On Wednesday, 7 February 2018 19:12:09 UTC, Shark8  wrote:
> On Wednesday, February 7, 2018 at 11:25:48 AM UTC-7, Lucretia wrote:
> > Well, I was going to reply to the deleted message.
> 
> I didn't even see the deleted message.

He was asking for a tl;dr
 
> > I scanned down this massive doc, this looks like a callback mechanism from an anonymous task.
> 
> Hm, I don't think that's nearly what's going on here (I've read most of it) because there's refinements which allow better worst-case analysis AND open up the possibility for more varied scheduling in SPARK.

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Simon Wright]

guyclaude.burger@gmail.com writes:

> That paper is huge, no wonder no one (seems to) dares to review
> it. Could you make a summary, or a short exposé on why "loop delay
> until ..." or similar statements are not enough to implement neatly
> the desired semantic ?

Not that big for a thesis, though it does seem a bit repetitive. The pix
seemed a bit OTT, I guess I'm just old-fashioned. And English.

He made criticisms of the -sfp- RTSs which don't apply to the -full-
versions; e.g. no memory allocation, no inheritance (and, by the way,
the -sfp- version *does* provide memory allocation, just not
deallocation). We have to remember that it takes a lot of time to work
to a doctorate, and keeping up with AdaCore improvements wouldn't add a
lot.

The problem with implementing the desired task paradigms with 'delay
until' etc is that although you could do it with a lot of distributed
effort (including use of tasking libraries as in GNATCOLL) it wouldn't
be easy to work out whether the system would meet its deadlines, with a
tool or by hand. And there'd be lots of opportunity for mistakes.

Another point I noticed was that he doesn't like the way an entry
released by an interrupt handler runs in the context of the task that
happened to be running at the time of the interrupt. I can't get too
excited about that, the interrupt had to be handled, and the code in the
entry shouldn't(*) be lengthy.

He says (p.158) "running a protected procedure handler in response to an
interrupt [...] invokes a context switch" which is not true.

My personal view of the AdaCore BB RTS is that it's fiendishly
complicated. I suppose that to meet all the ARM requirements it has to
be. Some of this appears to be for portability. The package call graph
is deeply nested.

I ws interested to see the claim that AdaCore BB RTS won't allow an MCU
to enter a low-power mode. I've not had occasion to try it out, but
FreeRTOS (which my Cortex GNAT RTS[1] runs on) does support this.

(*) not a good position to be in if your system is severely CPU-bound;
but in that case, would you believe the theoretical calculations anyway?

[1] https://github.com/simonjwright/cortex-gnat-rts

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Mark Lorenzen]

On Wednesday, February 7, 2018 at 11:04:33 PM UTC+1, Simon Wright wrote:

> I ws interested to see the claim that AdaCore BB RTS won't allow an MCU
> to enter a low-power mode. I've not had occasion to try it out, but
> FreeRTOS (which my Cortex GNAT RTS[1] runs on) does support this.

Yes this claim seems rubbish to me. It is true that the AdaCore BB run-time idle loop is a busy loop which doesn't enter low-power mode, but this can be implemented by a lowest-priority task with an infinite loop entering low-power mode.

On a LEON3 platform we assigned the lowest priority to the environment task and implemented such an infinite loop in the main program. It works very well.

Regards,

Mark L

Re: Reducing the cost of real-time software through a cyclic task abstraction for Ada

[Shark8]

On Thursday, February 8, 2018 at 3:25:45 AM UTC-7, Mark Lorenzen wrote:
> On Wednesday, February 7, 2018 at 11:04:33 PM UTC+1, Simon Wright wrote:
> 
> > I ws interested to see the claim that AdaCore BB RTS won't allow an MCU
> > to enter a low-power mode. I've not had occasion to try it out, but
> > FreeRTOS (which my Cortex GNAT RTS[1] runs on) does support this.
> 
> Yes this claim seems rubbish to me. It is true that the AdaCore BB run-time idle loop is a busy loop which doesn't enter low-power mode, but this can be implemented by a lowest-priority task with an infinite loop entering low-power mode.
> 
> On a LEON3 platform we assigned the lowest priority to the environment task and implemented such an infinite loop in the main program. It works very well.

Interesting, but I think the pertinent parts in the paper are the better WCET analysis. (And, since he *was* in touch with AdaCore it's entirely possible that they were alerted to the problem and made a fix like yours / that allowed yours.)