Elliott.Rachlin@Honeywell.com raised an interesting scenario today that
highlights the need for, at least, one of the services proposed in
this PCR, and has funding to help make it happen.

    The Epic group would like to run various high rate control
    applications at a rate faster than the periodic rate that can
    usefully be assigned on their platform due to Deos overhead
    "taxes".  It turns out that the design naturally is partitioned so
    that a high rate ISR will respond to an interrupt, and that a
    small number of other threads (likely in other processes) *might*
    need to subsequently perform further action, and these threads
    have the same low latency response requirements as the original
    ISR.

Currently there is no means in Deos where a thread can both elevate
its priority above periodic rate, and wait with access to its fixed
budget, other than waitForNextInterrupt().

Using either the "send an exception to thread in other process" (to
abort an interrupt wait) or the "raise interrupt" mechanisms proposed
by this PCR would enable the Epic requested operation, although the
"raise interrupt" proposal seems the cleanest for this particular
application.


Elliott has a work around (using high priority slack consumers) for his
proof of concept.  Current best guess is he would need a prototype
implementation for a demonstration approximately EOY 2006.

Random Implementation Notes:
----------------------------

I can't think of any scheduling or time partitioning issues for "raise
interrupt".  Presumably the time to raise the interrupt would be
charged to the calling thread, and since interrupts are asynchronous,
there would be no special issues on the handler's part.

It is also worth noting that prior to the Agave slack optimizations,
this approach would be highly expensive since any not used ISR budgets
would be allocated to IDLE rather than slack.

Clearly there would have to be access control specified on the event's
part.  This certainly would have been cleaner if interrupts were a
kind of event.

Assuming a worst case scenario where we will only be able to perform this work if it is customer funded, CCB will likely want an estimate to complete this change in terms of person-months of effort.  One should include all steps up to and including publishing the SAS.  CCB would also need to know how much funding has been set aside by the customer to pay, and when in '07 the certification work is to be complete.  

I spoke with Elliott about this feature request PCR.  For 2006
they can use a non certified release.  My guestimate is that the total
cost to develop and certify this feature is 5-10 months of effort
(which I believe to be conservative).  For a non certified version,
we're probably talking 4-6 weeks (implement, document, and informal
test), which Elliott said they had some funding this year to cover.
If the project is approved, we'd negotiate for the remaining balance
for 2007.

I had a thought, what if instead of adding a raise interrupt to other thread we added an additional resource wait type that had interrupt characteristics? (i.e. the waiter was woken immediately and allowed to run if it had fixed budget left.)  This could happen arbitrarily close to the threads period boundary so they would have to deal with the fact that it did not gets it's full budget but the same is true for an ISR thread.  This type a feature would allow threads at any rate to become aperiodic.  This is just an off the wall idea I had.  It defiantly has limitations (for one schedule before threads could not do it).  Before we could implement it we would need to some deep analysis of RMA and Deos's implementation of it.  One thing I think that we would need to push on is why ISR threads must be tick rate.

Update Target Milestone per 3/2006 Deos ADIRU Final EASA audit.

*** Bug 4101 has been marked as a duplicate of this bug. ***

I concur with comment #4.  It seems like a very good idea.  If we did that, then it also seems like having a sub-period timer would be very handy.  Basically the ability for a long period thread to wait several MS without needing to suspend for a whole period.  Seems to be poor fit for periodics, but it might make more sense for aperiodics.

CCB visited this PCR on 2010-02-03

CCB visited this PCR on 2010-02-25.

CCB 2 visited this PCR on  2010-03-31

CCB visited this PCR on 2010-05-11

CCB 2 visited this PCR on 2010-09-30.

CCB visited this PCR on 2010-12-17.

CCB visited this PCR on 2011-03-07

CCB visited this PCR on 2011-04-11

CCB2 visited this PCR on 2011-05-16

CCB visited this PCR on 2011-08-17

CCB 2 visited this PCR on 2011-11-04

CCB visited this PCR on 2012-01-31

CCB visited this PCR on 2012-05-15

CCB 2 visited this PCR on 2012-06-08

CCB visited this PCR on 2012-08-24

CCB visited this PCR on 2012-09-07

CCB visited this PCR on 2012-09-17

CCB visited this PCR on 2012-11-19

CCB visited this PCR on 2012-11-26

CCB visited this PCR on 2013-02-12

CCB visited this PCR on 2013-03-18

CCB visited this PCR on 2013-05-15

CCB visited this PCR on 2013-07-19

CCB visited this PCR on 2013-11-15

CCB 2 visited this PCR on 2014-05-20

CCB visited this PCR on 2014-07-14

CCB 2 visited this PCR on 2014-11-11

CCB visited this PCR on 2014-11-17

CCB visited this PCR on 2016-04-18

CCB visited this PCR on 2016-06-20

CCB visited this PCR on 2017-02-01-59501

CCB visited this PCR on 2017-06-28-69227

CCB visited this PCR on 2017-07-06-58325

CCB visited this PCR on 2018-03-06-71236

CCB visited this PCR on 2021-03-26-57787

CCB visited this PCR on 2021-04-05-59141

CCB visited this PCR on 2023-08-14-64795

This PCR will be required for supporting 653 and posix once the scheduler is updated.  It is being taken off of HOLD for consideration for Kismet.

CCB visited this PCR on 2024-04-04-71881

CCB visited this PCR on 2024-08-30-49739