RealtimeThreads

From Suhrid.net Wiki
Revision as of 14:17, 3 October 2012 by Suhridk (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Intro

  • Java has threads but they are not expressive enough to capture properties of real time activities. (e.g. deadline, cost, value etc.)
  • RT threads are also characterized by their execution patterns - periodic, sporadic, aperiodic. This has to be manually coded in standard Java threads.
  • Supporting RT Threads requires fundamental changes to the JVM.
  • Two classes: RealtimeThread and NoHeapRealtimeThread.

Periodic RT Thread

  • waitForNextPeriod() : Causes the current real-time thread to be suspended until the beginning of the next period. Each time it is called this method will block until the start of the next period unless the thread is in a deadline miss condition. In that case the operation of waitForNextPeriod is controlled by this thread's scheduler. Returns True (when the thread is next released ) when the thread is not in a deadline miss condition. Otherwise the return value is governed by this thread's scheduler.
    • Suppose a thread starts running (first release) at time t=0 and has a period of time 10 units. Then the next period is due at time t=20. The release events are separated by 10 time units irrespective of when the thread finishes.
  • The deschedulePeriodic() method will cause the associated thread to block (to be descheduled) at the end of its current release (when it calls waitForNextPeriod). It will then remain descheduled until schedulerPeriodic() is called.
public class PeriodicRT1 {

	public static void main(String[] args) {
		
		ReleaseParameters rp = new PeriodicParameters(new RelativeTime(3000,0));
		
		RealtimeThread prt = new RealtimeThread(null, rp) {
			boolean go = true;
			public void run() {
				while(go) {
					System.out.println("PRT computing");
					System.out.println("Calling WFNP @ " + System.currentTimeMillis());
					go = waitForNextPeriod();
					System.out.println("WFNP Returned @ " + System.currentTimeMillis());
				}
			}
		};
		
		prt.start();
		
	}
}
  • DL Miss handler can be defined as part of Release Parameters. If no DL Handler is defined, missed DL count is kept.
  • The behaviour of waitForNextPeriod (WFNP) can be described in terms of:
    • lastReturn: indicates last return value from wFNP.
    • missCount : DL miss count.
    • descheduled: should thread be descheduled at end of current release.

SO States

  • A SO can be in three states:
    • Blocked
      • Means cant have status changed to executing.
      • Blocked for release event.
      • Blocked for reschedule.
      • Blocked for cost replenishment.
    • Eligible for Execution: SO's state can be changed to executing.
    • Executing: means SO is running.

Cost Overrun

  • Under the priority scheduler, a cost overrun results in the periodic real-time thread being immediately automatically descheduled (that is, it becomes not eligible for execution) and any cost overrun handler released.
  • The real-time thread will not be rescheduled (made eligible for execution) until either its next release occurs (in which case its CPU budget is automatically replenished with the cost value) or its associated cost value is increased.

DL Miss

  • So unlike cost overrun, the thread is not immediately descheduled.
  • On each DL miss:
    • If the thread has a DL Miss Handler
      • Value of descheduled is set to true and DL miss handler is released with its fireCount incremented.
    • Else
      • Missed DL count is incremented.

Period Due

  • When each period is due:
    • If thread is waiting for next release
      • If descheduled is true, nothing happens.
      • If descheduled is false, thread is made eligible for execution, cost budget replenished and pendingReleases incremented. [TODO Why ?]
    • Else
    • Pending Releases is incremented (For e.g. thread may still be running). If thread is blocked for cost replinshment, it is made eligible for execution and scheduled.

Schedule and Deschedule Periodic

  • When schedulePeriodic is called (e.g. called by DL Handler to reschedule the RT Thread)
    • descheduled is set to false.
    • if thread is blocked-for-reschedule, pendingRelease will be zero, and is made blocked-for-release.
  • When deschedulePeriodic is called, descheduled is set to true.

WFNP Semantics

  • If missCount is > 0 then the Misscount is decremented.
    • If lastReturn from wFNP is true - previous release has not missed its DL. Then wFNP returns false immediately. This situation indicates that the current release has missed its deadline. At this point, the current release is still active (this means the current bud- get is unaltered).
  • ELSE
    • If lastreturn from wFNP is false, This situation indicates that the next release time has already passed and the next deadline has already been missed. At this point, the current release has completed and the next release is active (and if it has not been allocated already, a new budget of cost is allocated). TODO: How ?
      • PendingRelease decremented, and false returned again. (next release has already missed its DL)
  • When a DL Miss handler is released, and DL miss count = 0. (When thread exceeds DL, DL Handler is automatically released and DL Miss count is decremented), then thread calls wFNP.

wFNP now deschedules the thread until a call to schedulePeriodic occurs. Once schedulePeriodic returns, wFNP returns true. At this point, the next release is active (and a new budget of cost is allocated).

  • When the deadlineMiss count = 0 and no deadline has been missed on the current release and the time for the next release has passed (maybe thread was pre-empted by another thread), then wFNP returns true immediately. At this point, the next release is active (and a new budget of cost is allocated).
  • When the deadlineMiss count equals zero and no deadline has been missed on the current release and the time for the next release has not passed, (all is well case) wFNP returns true at the next release time.

At which point, the next release is active (and a new budget of cost is allocated.

  • If descheduled is true
    • Thread is made blocked-for-reschedule until it is notified by a schedulePeriodic. Thread keeps waiting to be rescheduled again.
    • Once schedulePeriodic is called, it becomes blocked-for-release. When release occurs:
      • pendingRelease decremented.
      • lastReturn is set to true and true is returned.
  • If descheduled is false
    • pendingReleases <= 0 : thread becomes blocked for release event.
    • pendingRelease > 0. Decrement pendingRelease and true is returned.

Important

  • If the programmer has set up the appropriate deadline miss handler, the RTSJ assumes that the handler will take some corrective action and then (if appropriate) reschedule the thread by calling the schedulePeriodic method. In this situation, waitForNextPeriod returns at the next release time following the call to schedulePeriodic . All releases in between are lost.
  • If the programmer has not set up the appropriate handler, the waitForNext- Period method will not deschedule the real-time thread in the event of a dead- line miss. The RTSJ assumes that in this situation the thread itself will undertake some corrective action and then call waitForNextPeriod again. In this situation, the application may suffer a cost overrun if the time to handle the condition has not been accounted for in the cost parameter.

DL Handler Priority

  • The deadline miss handler is a schedulable object.
  • Consequently, it will compete with its associated schedulable object according to their priority. Hence, for the handler to have an impact on the errant realtime thread it must have a priority higher than the thread.
  • If the priority is lower, it will not run until the errant thread blocks. For e.g. RTThread can miss deadline, at which point the DL Handler is called. It can keep working till the next call to wFNP. The DL Handler will not be able to take corrective action because of its low priority.


Deadline miss handlers can be dynamically added and removed while the real-time thread is executing. The RTSJ has two simple rules to ensure that the behavior of the waitForNextPeriod method is well defined :

  1. when a deadline miss occurs and a handler is released, the fireCount of the handler is increased by the deadlineMiss count + 1, and the deadline Miss count is set to zero
  2. the waitForNextPeriod method always returns immediately if the deadlineMiss count is greater than zero irrespective of whether a deadline miss handler is still active.

Cost Overruns

  • If cost has overrun:
    • If thread has cost overrun handler, it is released.
    • If pendingRelease is zero
    • If thread is eligible for executing or is executing, thread becomes blocked-for-cost replenishment.
    • Otherwise thread is already blocked, so state transition deferred. [TODO: State transition to what ?]
    • If pendingRelease > 0 a release has already occurred, cost is replenished.

NoHeapRealtimeThread

  • One of the main weaknesses is that RealtimeThreads can be preempted by the GC Thread.
  • Therefore RTSJ has allowd memory to be defined in areas other than heap which are not Garbage Collected.
  • But RTThreads can also use heap memory.
  • A NoHeapRealtimeThread is a thread which only accesses non heap memory.
  • Therefore a NoHeapRealTimeThread can be safely executed when the GC is running.

Sporadic/Aperiodic RT Thread

  • Unlike periodic, they have no start time. So they can considered to be released as soon as they are started.
  • How do they indicate to scheduler that they have completed current execution and have to be re-released ?
  • WFNP cannot be used because that only works with Periodic Parameters.
  • Programmer needs to provide his own mechanisms.
  • It is currently not possible for the RTSJ to detect either deadline miss or cost overruns for these activities, as there is no notion of a release event.
  • Indeed, programmers are best advised to use Async Event handlers to represent non-periodic activities.