JSR-282 SI 1.4: Supporting Sporadic and Aperiodic Releases in Real-Time Threads -------------------------------------------- Last Updated: 25th April, 2006 ----------------------- Summary ------------- The proposal is to add waitForNextRelease(), waitForNextReleaseInterruptible(), release(), schedule() and deschedule() methods to RealtimeThread so real-time threads will be better able to handle sporadic and aperiodic processing. Specification References ----------------------- Chapter 5: Semantics and Requirements for Real-Time Threads Chapter 6: Scheduling: Semantics and Requirements: Periodic Release of Real-Time Threads; Aperiodic Real-Time Threads Problem being address ------------------------------ The current specifications supports a range of ReleaseParameters that can be associated with schedulable objects. Asynchronous event handlers support the full range, however, currently there is no appropriate mechanisms to support associating AperiodicParameters and SporadicParameters with real-time threads. This is because there is no notion of a real-time thread waiting for a next release. It can only call waitForNextPeriod (which throws an exception if the real-time thread does not have PeriodicParameters). This also means that it is impossible to support the deadline miss and cost overrun detection mechanisms. Also aperiodic and sporadic threads cannot be descheduled in the same way as periodic threads. The current workaround is either not to use aperiodic/sporadic real-time threads or to assume that aperiodic/sporadic real-time threads are single shot (that is they are released by a call to the start method and they complete by termination - this is what the current spec says). Both these approaches undermine the consistency of the specification. Proposed Solution Summary -------------------------------------- The proposed solution is to 1) Add the following methods to the RealtimeThread class a) waitForNextRelease and waitForNextReleaseInterruptible b) release c) deschedule d) schedule 2) Define waitForNextRelease (when the real-time thread has aperiodic or sporadic release parameters) to be subjected to the semantics defined in Aperiodic Release Control (page 73 in the 2nd Edition) and Sporadic Release Control (page 75 in the 2nd Edition). (These sections are already written in terms of schedulable objects.) 3) Define deschedule and schedule (when the real-time thread has aperiodic or sporadic release parameters) to be consistent with that defined in Periodic Release of Real-Time threads (page 69 of the 2nd Edition). 4) Apply the current semantics for deadline miss and cost overrun (for a real-time thread that has periodic release parameters) to all release parameter types 5) Apply the methods defined in 1) above to real-time threads with PeriodicParameters: such that 5a) waitForNextRelease is defined to have the same semantics as waitForNextPeriod. 5b) deschedule is defined to have the same semantics as deschedulePeriodic 5c) schedule is defined to have the same semantics as schedulePeriodic. 6) Treat the changing of release parameter types as a pseudo re-start of the real-time thread. Semantics of Proposed Solution ---------------------------------------- The proposal is to provide a set of consistent mechanisms for controlling the release and completion of real-time threads. The current specification for cost monitoring is already defined in terms of releases of schedulable objects. Hence these semantics automatically apply to real-time threads with sporadic and aperiodic release parameters. The full semantics of this proposal can be generated from the current specification of the semantics in the "Periodic Release of Real-Time Threads" (page 69 of the 2nd Edition) modified to take into account the semantics defined in Aperiodic Release Control (page 73) and Sporadic Release Control (page 75). Essentially the proposed semantics are identical if you view a release event as coming from either the passage of time (for a periodic thread only) or the call of the release method (if and when it generates a release event). Deadline misses are handled in an identical way. public static boolean waitForNextRelease() Signals completion of the current release of the real-time thread and (in the absence of any missed deadline) blocks the real-time thread until a release event occurs waitForNextRelease() has comparable semantics to wFNP. In the normal case, it returns true when the real-time thread is next release. It returns false immediately if the real-time thread has missed its deadline and no deadline miss handler has been released. Real-time threads are automatically descheduled (at the end of the current released) when a deadline has been missed and a handler has been released. Alternatively, they can be descheduled explicitly by calling the deschedule method. public void release() Signals that the associated real-time thread should be released. May throw an exception if the thread is periodic (see Discussion point 1). public void deschedule() Indicates that the associated real-time thread should be removed from the list of threads eligible for scheduling at the end of its current release. public void schedule () Indicates that the associate thread can be added to the list of threads eligible for scheduling when the next release event for that thread occurs (subject to any MIT constraints if it has sporadic release parameters). Full Semantics of Aperiodic and Sporadic Release Control for Real-time Threads ------------------------------------------------------------------------------- ***The following assumes that the new methods are defined her for aperiodic real-time threads. The semantics for periodic real-time threads are unchanged. No attempt is made to unify the description of the semantics of periodic and aperiodic threads. (This would need to be done in the revised Specification.) The psuedo code given at the end is, however, for the genera case. A schedulable object with release parameters of type AperiodicParameters is expected to be released non periodically. For real-time threads non-periodic release behavior is achieved by executing in a loop and invoking the RealtimeThread.waitForNextRelease method, or its interruptible equivalent RealtimeThread.waitForNextReleaseInterruptible within that loop. For simplicity, unless otherwise stated, the semantics in this section apply to both forms of that method. When the release method of a real-time thread (with aperiodic or sporadic release parameters) is called, the associated real-time thread is released according to the semantics below: 1. A non-periodic real-time thread's release characteristics are determined by the following: a. The invocation of the real-time thread's start method. b. The action of the RealtimeThread methods waitForNextRelease, waitForNextReleaseInterruptible, schedule and deschedule; c. The occurrence of deadline misses and whether or not a miss handler is installed; and d. The calling of the release method that generates non-periodic release events 2. Each call to the release method is an arrival. If the real-time thread has release parameters of type AperiodicParameters, then the arrival may become a release event for the real-time thread, according to the semantics given in Aperiodic Release Control (see page 73 of the 2nd Edition of the book). If the real-time thread has release parameters of type SporadicParameters, then the arrival may become a release event for the real-time thread, according to the semantics given in Sporadic Release Control (see page 79 of the 2nd Edition of the book). If the real-time thread has release parameters of PeriodicParameters then the arrival has no effect. 3. For each release arrival that is accepted for a real-time thread, an entry is made in the arrival-time queue. 4. The initial release event of a non-periodic real-time thread occurs in response to the invocation of its start method. 5. The deadline for a release is relative to the release event time and determined at the release event time according to the value of the deadline contained in the real-time threads release parameters. This value does not change, except as described previously for real-time threads using a REPLACE policy for MIT violation or arrival-time queue overflow. 6. Subsequent release events occur with each call of the release method, except as described in Aperiodic Release Control and Sporadic Release Control, and below in 7(e). 7. The implementation should behave effectively as if the following state variables were added to a real-time thread's state, and manipulated by the actions in (1) as described below: boolean descheduled, integer pendingReleases, integer missCount, boolean lastReturn. a. Initially: descheduled = false, pendingReleases = 0, missCount = 0, and lastReturn = true. b. When the real-time thread's deschedule method is invoked: set the value of descheduled to true. c. When the real-time thread's schedule method is invoked: set the value of descheduled to false; then if the thread is blocked-for-release-event, set the value of pendingReleases to zero, and tell the cost monitoring system to reset for this thread. d. When descheduled is true, the real-time thread is said to be descheduled. e. A real-time thread that has been descheduled and is blocked-for-release-event will not receive any further release events until after it has been rescheduled by a call to schedule; this means that no deadline misses can occur until the thread has been rescheduled. The descheduling of a real-time thread has no effect on its initial release. f. When each release event is due: i. If the state of the real-time thread is blocked-for-release-event (that is, it is waiting in waitForNextRelease), then if the thread is descheduled then do nothing, else increment the value of pendingReleases, inform cost monitoring that the next release event has occurred, and notify the thread to make it eligible for execution; ii. Otherwise, increment the value of pendingReleases, and inform cost monitoring that the next release event has occurred. g. On each deadline miss: i. If the real-time thread has a deadline miss handler: set the value of descheduled to true, atomically release the handler with its fireCount increased by the value of missCount+1 and zero missCount; ii. Otherwise add one to the missCount value. h. When the waitForNextRelease method is invoked by the current real-time thread there are two possible behaviors depending on the value of missCount: i. If missCount is greater than zero: decrement the missCount value; then if the lastReturn value is false, completion occurs: apply any pending parameter changes, decrement pendingReleases, inform cost monitoring the real-time thread has completed and return false; otherwise set the lastReturn value to false and return false. ii. Otherwise, apply any pending parameter changes, inform cost monitoring of completion, and then wait while descheduled is true, or pendingReleases is zero. Then set the lastReturn value to true, decrement pendingReleases, and return true. 8. An invocation of the waitForNextReleaseInterruptible method behaves as described above with the following additions: a. If the invocation commences when an instance of AsynchronouslyInterrupted- Exception (AIE) is pending on the real-time thread, then the invocation immediately completes abruptly by throwing that pending instance as an InterruptedException. If this occurs, the most recent release has not completed. If the pending instance is the generic AIE instance then the interrupt state of the real-time thread is cleared. b. If an instance of AIE becomes pending on the real-time thread while it is blocked-for-release-event, and the real-time thread is descheduled, then the AIE remains pending until the real-time thread is no longer descheduled. Execution then continues as in (c). c. If an instance of AIE becomes pending on the real-time thread while it is blocked-for-release-event, and it is not descheduled, then this acts as a release event: i. The real-time thread is made eligible for execution. ii. Upon execution the invocation completes abruptly by throwing the pending AIE instance as an InterruptedException. If the pending instance is the generic AIE instance then the interrupt state of the real-time thread is cleared. iii. If the AIE becomes pending at a time tint then: * The deadline associated with this release is the time tint+Dint, where Dint is the value of the deadline stored in the real-time thread's release parameters object at the time tint. * The next release time for the real-time thread will be when the next release event occur.. iv. Cost monitoring is informed of the release event When the thrown AIE instance is caught, the AIE becomes pending again (as per the usual semantics for AIE) until it is explicitly cleared. 7. Changes to release parameter types are treated as a pseudo RE-START of the release-time thread and a) any old pending releases are cleared b) any old arrival queue is flushed c) any outstanding call to deschedule is cleared d) any outstanding deadline misses are cleared The semantics are described below: i) Feasibility set issue Parameters are changed immediately (as specified in current spec) Given the following, the scheduler knows when the impact will take effect. ii) Effect on real-time thread if it is not waiting for next release event (and is not descheduled) a) no effect until the end of current release -- as implied by current spec b) when change occurs Pseudo re-start of the thread. i.e. if new RP are aperiodic - release immediately if periodic - use periodic start time algorithm iii) Effect on real-time thread if it is not waiting for next release event (but there is an outstanding descheduled) Immediate implied schedule. a) no futher effect until end of current release -- as implied by current spec b) when change occurs Pseudo re-start of the thread i.e. if new RP are aperiodic - release immediately if periodic - use periodic start time algorithm 4) Effect on real-time thread if waiting for next release event (and not descheduled) a) From Periodic to Aperiodic - when next periodic release event, it now becomes aperiodic with an immediate release a) From Aperiodic to Periodic - Immediate pseudo re-start of the thread using periodic start time algorithm 5) Effect on real-time thread if waiting for next release event (but there is an outstanding descheduled) Immediate implied schedule. a) From Periodic to Aperiodic - when next periodic release event, it now becomes aperiodic with an immediate release a) From Aperiodic to Periodic - Immediate pseudo re-start of the thread using periodic start time algorithm Pseudo Code ------------ The semantics of the previous section (and how they are integrated with periodic scheduling) can be more clearly understood by viewing them in pseudo-code form for each of the methods and actions involved. In the following no mechanism for blocking and unblocking a thread is prescribed. The use of the wait and notify terminology in places is purely an aid to expressing the desired semantics in familiar terms. // These values are part of thread state. boolean descheduled = false; int pendingReleases = 0; boolean lastReturn = true; int missCount = 0; int currentRP; int newRP; int periodic = 1; int aperiodic = 2; int sporadic = 3; boolean RPchange = false; boolean started = false; // set to true on first release; changeReleaseParameters(int newP) { newRP = newP; // Change Feasibility set descheduled = false; // automatic re-schedule if(blocked-for-release-event) { if (currentRP == periodic) { // defer until next release RPChange = true; } else { // immediate change performParameterChanges(); // current is aperiodic or sporadic assert pendingReleases = 0 assert missCount = 0; started = false; // flush arrival queue costMonitoringReset(); currentRP = newRP; if(newRP == periodic) { // consider this as the equivalent of call the // start method of the RT thread. // If start time has passed, generate a // an "onNextPeriodDue" event. // Otherwise, arrange for the event to be // generate at the appropriate time } else { // aperiodic or sporadic // generate a releaseArrivalEvent } } } else { // not at end of release, defer change RPChange = true; } } deschedule(){ if (!RPChange && started) { // no deschedule if outstanding RPchange // or not started descheduled = true; } } schedule(){ descheduled = false; if (blocked-for-release-event) { pendingReleases = 0; // flush arrival time queue costMonitoringReset(); } } onAperiodicReleaseArrival() { if(!started) started = true; if (currentRP == periodic) throw IllegalThreadStateException; if (descheduled) { ; // do nothing } else { perform_any_execution_regulation // For a sporadic thread, the onReleaseDue event // will be generated when MIT concerns have been satisfied // For an aperiodic thread, this will // immediately generate an onReleaseDue event. } } onAperiodicReleaseDue(){ if(currentRP == periodic) throw panic; if (blocked-for-release-event) { if (descheduled) { ; // do nothing } else { pendingReleases++; notifyCostMonitoringOfReleaseEvent(); notify it; // make eligible for execution } } else { pendingReleases++; notifyCostMonitoringOfReleaseEvent(); } } onNextPeriodeDue(){ // also called on first release if(!started) started = true; if (currentRP != periodic) panic; if (blocked-for-release-event) { if (descheduled) { ; // do nothing } else { pendingReleases++; notifyCostMonitoringOfReleaseEvent(); notify it; // make eligible for execution } } else { pendingReleases++; notifyCostMonitoringOfReleaseEvent(); } } onDeadlineMiss(){ if (there is a miss handler) { descheduled = true; release miss handler with fireCount increased by missCount+1 missCount = 0; } else { missCount++; } } waitForNextRelease{ assert(pendingReleases >= 0); if (missCount > 0 ) { // Missed a deadline without a miss handler missCount--; if (lastReturn == false) { // Changes on completion take place here performParameterChanges(); notifyCostMonitoringOfCompletion(); if(RPchange) { RPChangeNow(); return true; } else { pendingReleases--; } } lastReturn = false; return false; } else { // Changes on completion take place here performParameterChanges(); notifyCostMonitoringOfCompletion(); if(RPchange) { RPChangeNow(); return True; } wait while (descheduled || pendingReleases == 0);// blocked-for-release-event // check again for RP change if(RPchange) { RPChangeNow(); } pendingReleases--; lastReturn = true; return true; } } changeRPNow { // Changing over RP // Assuming clean slate! RPchange = false; pendingReleases = 0; // flush arrival time queue missCount = 0; // restart here if(newRP == periodic) { // consider this as the equivalent of call the // start method of the RT thread. if !start time has passed { // arrange for timing event to be generated started = false; currentRP = newRP; wait while (pendingReleases == 0);// blocked-for-release-event } } else { // aperiodic or sporadic // record a releaseArrivalEvent } started = true; currentRP = newRP; lastReturn = true; } Discussion Points --------- 1. Should pendingReleases variable be visible to the programmer and should we provides methods to manipulate it in the same way that fireCount is visible? The current proposal assumes not. Arguments For: Asynchronous event handlers have access to a fireCount that contains the number of outstanding calls to their associated fire methods (for which there is no call to handleAsyncEvent). The equivalent for this in real-time threads is the pendingRelease count in the pseudo code. In order to achieve consistency across the models, a real-time thread should be able to access the pendingRelease count. Also, without this facility it would not be possible for the program to handle all outstanding releases in one go. That is: "clear all pending releases". Arguments Against: Asynchronous event handlers has a dynamic association between event handler and server thread. One of the motivations for the fireCount was to optimize the handling of the events to avoid some of the overheads associated with this dynamic association. By definition, real-time threads don't have this overhead and, therefore, don't need the access. There is no equivalent facilities for periodic threads. 2. Should the program be able to force a release of a periodic thread by calling release directly? The current proposal assumes not. Arguments for: Currently the specification defines that changes to some release parameter attributes don't take place until the next release of the schedulable objects (in particular a new periodic and a new deadline). Consider the case of a mode change where a periodic real-time thread needs to have its period and deadline changed from a long deadline to a short deadline. Currently, the start of the new mode could be delayed for a significant time. The work around in the current specification is to make the real-time thread use wFNPI and to interrupt it. This is subject to race conditions(the thread is potentially interrupted whilst executing the code for the last release of the old mode). With the proposal here, the thread initiating the mode change can force a new release of the real-time thread to occur immediately after the current release has completed by calling the release method. The new parameters are then installed and the the real-time threads starts the new mode with the new period and deadline. Hence allowing release to be applied to periodic threads gives extra flexibility and avoids having to raise an exception (which would be needed if we disallowed it). Arguments against: Releasing the real-time thread early will undermine the periodic thread model and cause extra complexity for feasibility analysis. It, therefore, has to be used in a very controlled way. 3) Should schedule and deschedule be moved to the Schedulable interface so that they can be applied to all schedulable objects? The current proposal assumes not. Arguments For: Currently they is no methods in the current specification for deschduling an ASEH other than detaching it from all its associated events (which may be difficult to determine). During transient overloads, it may be necessary to reduce the load on the processor by descheduling some ASEH. Arguments against: There is some concern as to whether this would be an incompatible change. Certainly, the specification would need to be revised to add deschedule and schedule to ASEH. However, it is not clear whether an RTSJ program compiled using 1.0.1 would execute correctly is run on a 1.1 implementation. Compatibility Issues -------------------- Any application that has extended the RealtimeThread classes and provided its own version of these methods may cause some confusion but should not be broken. Email History -------------- Subject: JSR282 Call Notes for 2006 Feb 2 Date: Thu, 2 Feb 2006 16:51:26 -0500 From: Dibble, Peter Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG Attending: Peter, Andy, Ben, Kelvin, Greg Discussing Andy's SI on waitForNextRelease Question: Should we have a waitForNextReleaseInterruptible? * Argument for no: We put the interruptible method in 1.0.1 because making wfnp interruptible would have broken compatibility * Argument for yes: The interruptible method treats the interrupt as a new release. If we just had one method (and it was interruptible) there would be no way to catch the interruption and go back to the last release. * Kelvin: The SI does not mention cost overrun semantics * Andy: It should inherit that kind of thing from wfnp. I'll revise the SI to make that more clear. It is in terms of releases. * Kelvin: Is this a place where we could tighten the semantics on what it means to miss a deadline. We don't (clearly) say how long after the miss the reaction has to happen. It should at least be in the doc requirements. Maybe it should be repeated here and there to remind people that nanoseconds might not always appear in reality. Pass this to the TIC. * Kelvin: It seems as if the SI calls for wfnp to be redefined in terms of wfnr. * Andy: The intention is that a app could use wfnr instead of wfnp as a more general form. * On the high level, everyone is happy with the general idea Discussing some of the issues in SI1 * Should schedule/deschedule be in the Schedulable interface? o Yes: An AEH that misses a deadline and has a miss handler now has to deschedule the underlying thread-thing. And the miss handler has to go to that thread and reschedule it. That means that the AEH has to stay locked to that thread while it is descheduled. o No: If it is in the Schedulable interface it would break source compatibility. o Option: Put it in AEH separately from the interface. Maybe a good idea, but we're too far from the SI * Should release work on a periodic SO? o No: This sounds ugly. It would break the periodic scheduling pattern. o Yes: Now you can get the same effect by interrupting wfnp. o Yes: If you want to change a release parameters value, you generally have to wait for the next release. If the period is really long and you want to shorten it, the delay could be a problem. o Andy will include some of this discussion in the next rev of the SI. -------- Original Message -------- Subject: [JSR282] WaitForNextRelease Date: Sat, 18 Feb 2006 13:05:00 +1000 From: David Holmes Reply-To: dholmes@ieee.org To: JSR-282-EG@JCP.ORG >From the call notes of Feb 2: > * Kelvin: It seems as if the SI calls for wfnp to be > redefined in terms of wfnr. > * Andy: The intention is that a app could use wfnr instead of > wfnp as a more general form. I agree with the need for wfnr to complement wfnp for aperiodics and sporadics. But I do not think they should be necessarily synonymous - we end up having two sets of semantics for each method: one if periodic and the other if not. If we consider wfnr() and release() as a form of wait/notify mechanism then there is really no need to tie them together. We could preclude the invocation of wfnr by a periodic thread as we preclude the invocation of wfnp by a non-periodic. Or for periodics we could simply elide all release/deadlines effects of calling wfnr. > * Should schedule/deschedule be in the Schedulable interface? > o Yes: An AEH that misses a deadline and has a miss handler > now has to deschedule the underlying thread-thing. And the miss > handler has to go to that thread and reschedule it. That means > that the AEH has to stay locked to that thread while it is descheduled. > o No: If it is in the Schedulable interface it would break > source compatibility. You can't add anything to existing interfaces without breaking backward source and binary compatibility. So simple answer is no. You'd have to define a new interface and have the top-level classes implement it. But language issues aside I don't see what semantics these methods would have for Schedulable objects in general. > o Option: Put it in AEH separately from the interface. > Maybe a good idea, but we're too far from the SI Again what is it supposed to mean? Does it stop a timer from firing an associated handler? does it cause fire() to skip a particular handler? does it stop an overrun or deadline miss handler from running? > * Should release work on a periodic SO? > o No: This sounds ugly. It would break the periodic > scheduling pattern. > o Yes: Now you can get the same effect by interrupting wfnp. > o Yes: If you want to change a release parameters value, > you generally have to wait for the next release. If the period > is really long and you want to shorten it, the delay could be a problem. No it breaks the periodic semantics. release() should only release thread blocked in wfnr and that should be distinct from wfnp. The problem of setting parameter values to affect the next release is non-trivial. There were two issues that drove the current semantics: - avoiding the need to have to change the time that a thread that is currently blocked must remain blocked. - not having to deal with changes that would put the next release in the past, and so have to figure out what this means for deadlines and cost. Looking at Andy's revised SI my main concern is that it seems to have overlooked the need to "copy over" all the semantics related to arrival queues, overflows and MIT violations, that we currently have for AEH. This might be straight-forward in terms of scheduling behaviour but what about "release counts"? Does release() for a RTT act like a fire() on an AE for an AEH? Does release() maintain a counter similar to the fireCount? If so then we have to deal with all that complexity too. If not, it is simpler but perhaps inconsistent. Here's a more extreme position. I think we need a notion of Schedulable Object as a scheduling/release-management abstraction but I think it has been a mistake to try to mirror the capabilities of AEH and RTT. If they are mirrored why do we need both? The two had different roles that now seem to be blurring. To that end I'd argue against adding waitForNextRelease. What is wrong with simply using threads for periodics, written in the idiomatic style using wfnp in a loop, and use AEH for sporadics? You don't need wfnr because you can code your thread using an AEH and an AE instead. Just a thought .. :) Cheers, David -------- Original Message -------- Subject: JSR282 Call notes 2006 Feb 20 Date: Mon, 20 Feb 2006 16:48:59 -0500 From: Dibble, Peter Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG Attending: Andy, Peter, David H., James, Kelvin First question, from David H. Should we do wfnr, or should we just let sporadics be done for AEHs. Ben: It does seem sort of asymmetric not to support it. Does this mean that the thread now needs all the release semantics from sporadics/aperiodics? Andy: Yes. My intention is that all those semantics be defined in one place and used for AEHs and wfnr. I'd be happiest if we could deprecate wfnp and use wfnr in both cases. :: The question is whether we are giving the programmer something useful by adding useful sporadic/aperiodic support to RTTs? Andy: We're not adding any real power, we're just supporting another programming model. Andy/David: Maybe we are adding power. A RTT can be descheduled/rescheduled, but that isn't supported on an AEH. James: Can't we consider deschedule of a thread to be equivalent to removing a handler for an AEH? Do we need a visible fire count in RTT? Andy: I'll have to think about that. It might not be a bad thing to have that asymmetry between AEH and RTT. David: Not having a fire count would make it so developers can't do the "drain the pending fire queue" thing. Ben: Maybe we can add an object parameter for release and let people pass in a value through the queue. ... or maybe that's too much. Peter: Maybe not, we have a work item to add a parameter to fire. David: What would feel most like Java events would be to pass the AE through the fire. Peter: Then what would we pass through release()? James: Maybe treat that like there's an event there? And wfnr would return the event. David H: A problem with passing an event through the fire ?handleAsyncEvent system is that decrementing the fire count would throw away data instead of just counts. Andy: But this only applies to AEHs. What does it have to to with wfnr and RTTs? David: By pulling events into wfnr, it makes the aperiodic/sporadic semantics map to the wfnr more smoothly. Andy: Update the SI to deal with fire count. Consider introducing an AE to the system. -------- Original Message -------- Subject: JSR282 Call notes for 2006 March 1 Date: Wed, 1 Mar 2006 16:33:23 -0500 From: Dibble, Peter Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG David: In Andy's updated SI. The pseudo-code should include release. There is an issue about where the MIT (regulation) takes place. Ben: In the proposed solution summary, what does optional mean? Andy: I want waitForNextRelease to behave like waitForNextPeriod if you call it for a periodic thread. There's been discussion of keeping them separated, so we could go either way. This option is for us to discuss, not for an implementation. Ben: In semantic 7.e., there is a reference to schedulePeriodic Andy: Hmm. Thank-you. I''ll do a grep for periodic Ben: In semantic 2 - where it says "sporadic" to you mean "aperiodic" or maybe "aperiodic or sporadic"? Andy: No, it needs an "else if" 11/3/2006 David Holmes wrote: >Good timing Andy this was on my to-do list this morning. > >Okay first the minor issue: > >Semantics 9 and 10 are confused. There should be one semantics for a AP/SP >SO becoming periodic; and the other for a periodic becoming AP/SP. But note >that the latter is already covered by the semantics for periodic threads; >and with the former the periodic semantics won't need its two case. (I hope >that was clear) > >Now the major issue: > >This proposal is a melding of the existing sporadic/aperiodics release >control with the periodic thread semantics. In bringing the two together I >am missing the exact relationship between things. For example, periodic >threads need pendingReleases to track elapsed release times; while ap/sp >have an arrival queue of release events. So when we have both of these what >is the relationship between them? Is pendingReleases the length of the >arrival queue? Does zeroing the pendingReleases clear the arrival queue? >Exactly how does a change in one affect the other? > >By following the "trail" some aspects of this relationship can be uncovered >but it is far from clear - particularly with our old friend MIT "SAVE" >(which complicates everything). For example in onReleaseArrival() you state: > > // for sporadic thread, the onReleaseDue event will be generated when MIT >concerns > // have been satisfied; for aperiodic this will immediately generate an >onReleaseDue > // event > >For any of the queue policies, and any of the MIT arrival time regulation >policies, we will either immediately get an exception, or simply update an >existing arrival queue entry, or we will immediately generate an >onReleaseDue event. So 99% of the time onReleaseArrival() either aborts or >immediately calls/triggers onReleaseDue(). > >The interesting case is MIT SAVE. With AEH execution time enforcement is >done in run() by the AEH. The logic is basically: > > ArrivalEvent a = arrivalQueue.take(); > while (lastReleaseTim - a.releaseTime < MIT) > delay(); > >Now the wording of onReleaseArrival makes it sounds as if it will perform >the delay, or at least cause a delay between the time that onReleaseArrival >is called and when onReleaseDue is triggerred. That seems quite different to >the AEH approach. To be the same as AEH I would expect the psuedo-code for >wfnr to have a delay_until_MIT_satisfied() clause in it. > >If you can address the question of how changes in pendingReleases affects >the arrival queue (and vice versa) then a clearer set of semantics will >emerge. They might not be the semantics we want but they should at least be >clear and consistent. > -------- Original Message -------- Subject: Re: JSR-282 WfNR Date: Mon, 13 Mar 2006 09:33:20 +0000 From: Andy Wellings Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG References: David Holmes wrote: >Good timing Andy this was on my to-do list this morning. > >Okay first the minor issue: > >Semantics 9 and 10 are confused. There should be one semantics for a AP/SP >SO becoming periodic; and the other for a periodic becoming AP/SP. But note >that the latter is already covered by the semantics for periodic threads; >and with the former the periodic semantics won't need its two case. (I hope >that was clear) > > > Actually semantics 7 and 8 on page 39 and 40 of the spec seems to cover both cases Do you think we need to say anymore? Andy -------- Original Message -------- Subject: Re: JSR-282 WfNR Date: Mon, 13 Mar 2006 09:54:19 +0000 From: Andy Wellings Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG References: David I think you are becoming too implementation focussed :-) >Now the major issue: > >This proposal is a melding of the existing sporadic/aperiodics release >control with the periodic thread semantics. In bringing the two together I >am missing the exact relationship between things. For example, periodic >threads need pendingReleases to track elapsed release times; while ap/sp >have an arrival queue of release events. So when we have both of these what >is the relationship between them? Is pendingReleases the length of the >arrival queue? Does zeroing the pendingReleases clear the arrival queue? >Exactly how does a change in one affect the other? > > I think we only need to add "// flush the arrival time queue" to the schedule pseudo code. >By following the "trail" some aspects of this relationship can be uncovered >but it is far from clear - particularly with our old friend MIT "SAVE" >(which complicates everything). For example in onReleaseArrival() you state: > > // for sporadic thread, the onReleaseDue event will be generated when MIT >concerns > // have been satisfied; for aperiodic this will immediately generate an >onReleaseDue > // event > >For any of the queue policies, and any of the MIT arrival time regulation >policies, we will either immediately get an exception, or simply update an >existing arrival queue entry, or we will immediately generate an >onReleaseDue event. So 99% of the time onReleaseArrival() either aborts or >immediately calls/triggers onReleaseDue(). > >The interesting case is MIT SAVE. With AEH execution time enforcement is >done in run() by the AEH. The logic is basically: > > ArrivalEvent a = arrivalQueue.take(); > while (lastReleaseTim - a.releaseTime < MIT) > delay(); > > This is one implementation only surely. My view is (and the spec says) that it is the scheduler that handles this aspect, Not the AEH. My assunption was that (logically) it is the scheduler that will generate the on_release_due event when the MIT has been satisfied. >Now the wording of onReleaseArrival makes it sounds as if it will perform >the delay, or at least cause a delay between the time that onReleaseArrival >is called and when onReleaseDue is triggerred. That seems quite different to >the AEH approach. To be the same as AEH I would expect the psuedo-code for >wfnr to have a delay_until_MIT_satisfied() clause in it. > >If you can address the question of how changes in pendingReleases affects >the arrival queue (and vice versa) then a clearer set of semantics will >emerge. They might not be the semantics we want but they should at least be >clear and consistent. > > Andy -------- Original Message -------- Subject: Re: JSR-282 WfNR Date: Mon, 13 Mar 2006 20:11:35 +1000 From: David Holmes Reply-To: dholmes@ieee.org To: JSR-282-EG@JCP.ORG Andy writes: > I think you are becoming too implementation focussed :-) Perhaps. But what I am trying to do is think through how an implementation might logically operate to see exactly what the semantics are. At the moment it isn't clear to me how the arrival queue and pendingReleases are related. If pendingRelease==arrivalQueue.length (which seems to be at least partly implied) then we can simply things by getting rid of pendingReleases. > I think we only need to add "// flush the arrival time queue" to > the schedule pseudo code. Perhaps - assuming that is the desired semantic. > >The interesting case is MIT SAVE. With AEH execution time enforcement is > >done in run() by the AEH. The logic is basically: > > > > ArrivalEvent a = arrivalQueue.take(); > > while (lastReleaseTim - a.releaseTime < MIT) > > delay(); > > > > > > This is one implementation only surely. My view is (and the spec says) > that it is the > scheduler that handles this aspect, Not the AEH. Yes that is only one implementation. The AEH/thread logically calls a blocking method that the scheduler causes to unblock at the "right" time. > My assunption was that (logically) it is the scheduler that will > generate the > on_release_due event when the MIT has been satisfied. Okay I'm starting to see how you are expressing this. I don't have a clear idea if this expresses what I think it does/should. I need more time to sort this out. David -------- Original Message -------- Subject: Re: JSR-282 WfNR Date: Mon, 13 Mar 2006 11:07:33 +0000 From: Andy Wellings Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG References: David Holmes wrote: >Andy writes: > > >>I think you are becoming too implementation focussed :-) >> >> > >Perhaps. But what I am trying to do is think through how an implementation >might logically operate to see exactly what the semantics are. At the moment >it isn't clear to me how the arrival queue and pendingReleases are related. >If pendingRelease==arrivalQueue.length (which seems to be at least partly >implied) then we can simply things by getting rid of pendingReleases. > > I would rather not do this at it allows for easy comparison with wFNP. Remember, we are NOT talking about what goes in the spec here. > > >>I think we only need to add "// flush the arrival time queue" to >>the schedule pseudo code. >> >> > >Perhaps - assuming that is the desired semantic. > > > >>>The interesting case is MIT SAVE. With AEH execution time enforcement is >>>done in run() by the AEH. The logic is basically: >>> >>> ArrivalEvent a = arrivalQueue.take(); >>> while (lastReleaseTim - a.releaseTime < MIT) >>> delay(); >>> >>> >>> >>> >>This is one implementation only surely. My view is (and the spec says) >> that it is the >>scheduler that handles this aspect, Not the AEH. >> >> > >Yes that is only one implementation. The AEH/thread logically calls a >blocking method that the scheduler causes to unblock at the "right" time. > > > >>My assunption was that (logically) it is the scheduler that will >>generate the >>on_release_due event when the MIT has been satisfied. >> >> > >Okay I'm starting to see how you are expressing this. I don't have a clear >idea if this expresses what I think it does/should. I need more time to sort >this out. > > Ok, will leave you in peace to thibnk about it :-) Go to bed now! Andy >David -------- Original Message -------- Subject: JSR282 Call notes from 2006 March 16 Date: Thu, 16 Mar 2006 17:08:42 -0500 From: Dibble, Peter Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG Attending: Peter, Andy, Sunil, David H., David B., Fridtjof, Kelvin, Ben Issue: Pratik joining the EG: OK him, but consider the EG closed (except for special cases) after that. ...--non relevant stuff State of the wfnr SI: It needs a bit more offline discussion. Peter: If a RTT switches from aperiodic to periodic should we flush the queue? If not, there may be a queue full of releases that must b e serviced by can't be touched by the APIs that work for a periodic thread. We could prohibit the change when the queue is full, or defer it until the queue empties, or flush the queue, or ... Is this an argument for making the queue accessible? Flag for further discussion. -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Mon, 20 Mar 2006 09:15:53 +0000 From: Andy Wellings Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG References: On the call last week, we identified an issue to do with changing between release parameter types. First some observations 1) Currently in the Spec, we do NOT require the base scheduler to check that an event handler that says it is released periodically is actually released periodically. 2) Here is what we currently say about parameter changes: 7. If an aperiodic real-time thread has its release parameters set to periodic parame ters, then calls waitForNextPeriod, the change from non-periodic to periodic scheduling effectively takes place between the call to waitForNextPeriod and the first periodic release. The first periodic release is determined by the start time specified in the real-time thread\u2019s periodic parameters. If that start time is an absolute time in the future, then that is the first periodic release time; if it is an absolute time in the past then the time at which waitForNextPeriod was called is the first periodic release time and the release occurs immediately. If the start time is a relative time, then it is relative to the time at which waitForNextPeriod was called; if that time is in the past then the release occurs immediately. Note, the implications of this is that any pending releases are lost. 8. If a periodic real-time thread has its release parameters set to be other than an instance of PeriodicParameters then the change from periodic to non-periodic scheduling effectively takes place immediately, unless the thread is blocked-forrelease- event, in which case the change takes place after the next release event. When this change occurs, the deadline for the real-time thread is that which was in effect for the most recent release. Here it is unclear what happens to any pending releases. 3) I cannot find anything that talks about changing release parameter types for AEH except the general SO statement about the change occuring immediately unless otherwize specified. Can anyone see anything more? I see several possible options 1) When changing ReleaseParameter types: firecounts and pending releases are set to zero 2) Don't zero counts but only allowing compatible changes, e.g. a) Periodic -> Sporadic : MIT must equal period b) Sporadic -> Periodic: Period must equal MIT c) Periodic -> Aperiodic: OK d) Aperiodic -> Periodic: DISALLOW - the resulting release pattern will not be periodic if there are outstanding releases e) Aperiodic -> Sporadic: either DISALLOW for essentially the same reason as d) or impose execution time regulation of the outstanding releases f) Sporadic -> Aperiodic: OK I think the simplist model is 1). Andy -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Sat, 25 Mar 2006 16:37:17 +1000 From: David Holmes Reply-To: dholmes@ieee.org To: JSR-282-EG@JCP.ORG Andy writes: > 2) Here is what we currently say about parameter changes: > > 7. If an aperiodic real-time thread has its release parameters set > to periodic parame > ters, then calls waitForNextPeriod, the change from non-periodic to > periodic > scheduling effectively takes place between the call to > waitForNextPeriod and > the first periodic release. The first periodic release is determined > by the start time > specified in the real-time thread\u2019s periodic parameters. If that > start time is an > absolute time in the future, then that is the first periodic release > time; if it is an > absolute time in the past then the time at which waitForNextPeriod > was called > is the first periodic release time and the release occurs > immediately. If the start > time is a relative time, then it is relative to the time at which > waitForNextPeriod > was called; if that time is in the past then the release occurs > immediately. > > Note, the implications of this is that any pending releases are lost. I wouldn't put it that way . You can only have "pending releases" after the set of release times has been established. The above establishes the very first release time for a newly periodic thread. Hence there can not be any pending releases when we do this. > 8. If a periodic real-time thread has its release parameters set to > be other than an > instance of PeriodicParameters then the change from periodic to > non-periodic > scheduling effectively takes place immediately, unless the thread is > blocked-forrelease- > event, in which case the change takes place after the next release > event. > When this change occurs, the deadline for the real-time thread is > that which was > in effect for the most recent release. > > Here it is unclear what happens to any pending releases. What possible pending releases are there? If the thread is not blocked-for-release-event ie in wfnp, then you've simply switched parameters. If there was a pending periodic release it is largely irrelevent (though make sure cost enforcement is informed of the switch!). If the thread is blocked in wfnp then there are either no pending releases or else it is descheduled. If there are no pending releases then it will be released when the next period is due. If it is descheduled then it will remain descheduled until rescheduled and then a period is due (all pending releases get ignored as per normal handling of descheduled periodics.) > 3) I cannot find anything that talks about changing release parameter > types for > AEH except the general SO statement about the change occuring immediately > unless otherwize specified. Can anyone see anything more? No. Because unlike the periodic thread to non-periodic thread (or vice versa) changes to AEH release characteristics don't involve a change in the release mechanism. > I see several possible options > > 1) When changing ReleaseParameter types: firecounts and pending releases > are set to zero > > 2) Don't zero counts but only allowing compatible changes, e.g. > > a) Periodic -> Sporadic : MIT must equal period > b) Sporadic -> Periodic: Period must equal MIT > c) Periodic -> Aperiodic: OK > d) Aperiodic -> Periodic: DISALLOW - the resulting release pattern will > not be periodic > if there are outstanding releases > e) Aperiodic -> Sporadic: either DISALLOW for essentially the same > reason as d) or impose > execution time regulation of the outstanding releases > f) Sporadic -> Aperiodic: OK > > > I think the simplist model is 1). Simple but not necessarily appropriate. I don't think the scheduler should do anything other than apply the rules given the current release parameters. If there are outstanding releases then they were accepted under the rules that applied at the time. If honoring those releases violates the new periodic release parameters then that is an application error. I don't see why you would want to switch release characteristics in general, but if you did then the basic process should be: 1. Prevent any new releases from the old non-periodic source 2. Finish any pending releases from that old source (which might just mean clearing the penbding fire count) 3. Attach the AEH to the new periodic source The issue with having the system clear the arrival queue and zero the firecount, is that such a change would be asynchronous with respect to the AEH's execution. This seems to be an almost arbitrary choice but I don't see any compelling reason to add these semantics. Cheers, David -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Mon, 27 Mar 2006 09:07:33 +0100 From: Andy Wellings Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG References: David Holmes wrote: >Andy writes: > > >>2) Here is what we currently say about parameter changes: >> >> 7. If an aperiodic real-time thread has its release parameters set >> to periodic parame >> ters, then calls waitForNextPeriod, the change from non-periodic to >> periodic >> scheduling effectively takes place between the call to >> waitForNextPeriod and >> the first periodic release. The first periodic release is determined >> by the start time >> specified in the real-time thread\u2019s periodic parameters. If that >> start time is an >> absolute time in the future, then that is the first periodic release >> time; if it is an >> absolute time in the past then the time at which waitForNextPeriod >> was called >> is the first periodic release time and the release occurs >> immediately. If the start >> time is a relative time, then it is relative to the time at which >> waitForNextPeriod >> was called; if that time is in the past then the release occurs >> immediately. >> >>Note, the implications of this is that any pending releases are lost. >> >> > >I wouldn't put it that way . You can only have "pending releases" after the >set of release times has been established. The above establishes the very >first release time for a newly periodic thread. Hence there can not be any >pending releases when we do this. > > What happens if we go from periodic - aperiodic - periodic For a relative start time, doesn't the above imply a new start? I still think you can have pending releases. > > >> 8. If a periodic real-time thread has its release parameters set to >> be other than an >> instance of PeriodicParameters then the change from periodic to >> non-periodic >> scheduling effectively takes place immediately, unless the thread is >> blocked-forrelease- >> event, in which case the change takes place after the next release >> event. >> When this change occurs, the deadline for the real-time thread is >> that which was >> in effect for the most recent release. >> >>Here it is unclear what happens to any pending releases. >> >> > >What possible pending releases are there? > Well in the case where we are well over our deadline for instances, there may be many pending releases >If the thread is not >blocked-for-release-event ie in wfnp, then you've simply switched >parameters. If there was a pending periodic release it is largely irrelevent >(though make sure cost enforcement is informed of the switch!). > I would have thought that you would violate MIT, as they are already arrivals. >If the >thread is blocked in wfnp then there are either no pending releases or else >it is descheduled. If there are no pending releases then it will be released >when the next period is due. If it is descheduled then it will remain >descheduled until rescheduled and then a period is due (all pending releases >get ignored as per normal handling of descheduled periodics.) > > > >>3) I cannot find anything that talks about changing release parameter >>types for >>AEH except the general SO statement about the change occuring immediately >>unless otherwize specified. Can anyone see anything more? >> >> > >No. Because unlike the periodic thread to non-periodic thread (or vice >versa) changes to AEH release characteristics don't involve a change in the >release mechanism. > > Not the release mechanisms but the release behaviour. Suppose you go from sporadic (MIT 5) to periodic (period 10) with accepted release events. What happens to them? > > >>I see several possible options >> >>1) When changing ReleaseParameter types: firecounts and pending releases >>are set to zero >> >>2) Don't zero counts but only allowing compatible changes, e.g. >> >>a) Periodic -> Sporadic : MIT must equal period >>b) Sporadic -> Periodic: Period must equal MIT >>c) Periodic -> Aperiodic: OK >>d) Aperiodic -> Periodic: DISALLOW - the resulting release pattern will >>not be periodic >>if there are outstanding releases >>e) Aperiodic -> Sporadic: either DISALLOW for essentially the same >>reason as d) or impose >>execution time regulation of the outstanding releases >>f) Sporadic -> Aperiodic: OK >> >> >>I think the simplist model is 1). >> >> > >Simple but not necessarily appropriate. I don't think the scheduler should >do anything other than apply the rules given the current release parameters. >If there are outstanding releases then they were accepted under the rules >that applied at the time. If honoring those releases violates the new >periodic release parameters then that is an application error. > > So we need to raise exceptions? >I don't see why you would want to switch release characteristics in general, > > In general I agree but there are some grey cases. Consider a thread which controls a thruster. When asked to fire, it is periodic, but only for the duration of the burns. Hence it is sporadically periodic! Of course we could model this in other ways (deschedule and reschedule). >but if you did then the basic process should be: > >1. Prevent any new releases from the old non-periodic source > > How can you do this? Are you going to get the system to look for all the ASE for which this is a handler, or just ignore the firings? >2. Finish any pending releases from that old source (which might just mean >clearing the penbding fire count) > > Who clears it, the system ? >3. Attach the AEH to the new periodic source > > It might be the same source? The ASE may not be changing. >The issue with having the system clear the arrival queue and zero the >firecount, is that such a change would be asynchronous with respect to the >AEH's execution. > > Yes, but so is any manipulation of these things by the system. I think we need to discuss this one on a call. cheers Andy >This seems to be an almost arbitrary choice but I don't see any compelling >reason to add these semantics. > >Cheers, >David > > -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Mon, 27 Mar 2006 19:18:58 +1000 From: David Holmes Reply-To: dholmes@ieee.org To: JSR-282-EG@JCP.ORG You are right Andy. There are so many weird ways that people could switch parameters back and forth, and do so after deadline misses, that the only thing we can do that prevents us having to think about all these possibilities is to have changing the release parameters cause a "clean slate". I think this should apply for all calls to setReleaseParameters even if changing from Periodic to Periodic etc. So switching when periodic will zero pending releases, and switching when aperiodic/sporadic will clear the arrival queue. If we apply the existing semantics of switching to periodic, that effectively re-asserts the start time, then this would also give a way to change the period "immediately", albeit with some hand-over jitter. David -------- Original Message -------- Subject: Call notes 2006 March 30 Date: Thu, 30 Mar 2006 17:14:17 -0500 From: Dibble, Peter Reply-To: Java Community Process JSR #282 Expert List To: JSR-282-EG@JCP.ORG Attending: Ben, Peter, Andy, David H., Kelvin, Sunil, Pratik, James Wfnr The current thought on changing parameters between periodic and aperiodic is to do it immediately and clear all pending releases. In the current spec, when one changes from periodic to aperiodic, there is little impact on the thread. It doesn't have to _do_ anything about the change so relatively light semantics are OK. If we don't change immediately, then a thread that changes to aperiodic will have to remember to call waitForNextPeriod even though it has made itself aperiodic. This argues for having wfnp and wfnr be equivalent. Since other SOs can change an thread's release parameters this puts an SO into a bad spot trying to figure out whether to call wfnr or wfnp. The other solution is to defer the change to the next release. Then the right way to terminate the release is set at the time the release takes place. Note that the feasibility set can get out of sync with reality when changes are placed in the feasibility set faster than the deferred changes take effect. It will always report on the set of parameters, not on the current state of the system. The most likely use case for switching parameter types might be a thread that waits for an event (someone pushes the button), then does something periodic for a while; e.g., they start the motor or fire the weapon. If we stay consistent with the current semantics, the change to the feasibility set will take place immediately, and the thread's behavior changes at the next release. James wishes we could forbid threads from accepting parameter type changes from other threads. While this would break compatibility, would it actually break any code? Why would anyone do this? David: Thread pools Andy: This should not be so hard: * Feasibility set changes immediately * Thread behavior changes at next release * Change the pseudo-code so on next period due says to check for parameter changes and implement them. Argument about whether the check should take place before or after or before and after the block in wfn(x). Checking before is good for threads that change their own parameters, but would make it hard to tell when the change would take effect if the changes come from another thread. (If they miss the window before the thread calls wfnr, the behavior won't change for a release, if they get in before the call the thread's behavior will change quickly.) Checking after is most consistent with what we have for wfnp, but it would not be as natural for a thread changing its own parameters. (Note from Peter while finishing these notes: Maybe add a static method (thus only usable on the currently executing thread) t hat causes the parameters to change before the thread blocks in the next wfnr?) -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Fri, 31 Mar 2006 14:14:39 +0100 From: Andy Wellings To: JSR-282-EG@JCP.ORG CC: Andy Wellings References: Guys Following from our recent call, I would like to get agreement on the following principles before I attempt to generate the pseudo code. Inevitably, there is an element of the following being an arbitrary position to take, but I believe it is coherent, and defensible :-) The key point is that I want to view a ReleaseParameter change (when it does occur) as a pseudo RE-START of the thread and for it to a) clear any old pending release b) flush any arrival queue c) clear any deschedule d) clear any deadline miss counts I think if we can agree this, life will be easier! NOTE, this does not say when this occur just what it means when it does occur. If you can live with this, then read on :-) 1) Feasibility set issue parameters changed immediately - as specified in current spec Given the following, the scheduler knows when the impact will take effect. 2) Effect on real-time thread if it is not waiting for next release event (and not descheduled) a) no effect until end of current release -- as implied by current spec b) when change occurs Pseudo re-start of the thread. i.e. if new RP are aperiodic - release immediately if periodic - use periodic start time algorithm 3) Effect on real-time thread if not waiting for next release event (but there IS an outstanding descheduled) Immediate implied schedule. a) no futher effect until end of current release -- as implied by current spec b) when change occurs Pseudo re-start of the thread i.e. if new RP are aperiodic - release immediately if periodic - use periodic start time algorithm 4) Effect on real-time thread if waiting for next release event (and not descheduled) a) From Periodic to Aperiodic - when next periodic release event, it now becomes aperiodic with an immediate release a) From Aperiodic to Periodic Immediate pseudo re-start of the thread. 5) Effect on real-time thread if waiting for next release event (but there IS an outstanding descheduled) Immediate implied schedule. a) From Periodic to Aperiodic - when next periodic release event, it now becomes aperiodic with an immediate release a) From Aperiodic to Periodic Immediate pseudo re-start of the thread - use periodic start time algorithm Andy -------- Original Message -------- Subject: Re: JSR-282 WfNR - changing between release parameters Date: Sat, 1 Apr 2006 11:55:41 +1000 From: David Holmes Reply-To: dholmes@ieee.org To: JSR-282-EG@JCP.ORG Andy, I think this is reasonable. I'll reserve judgement on some of the details but the approach seems reasonable. :) Cheers, David