Difference between revisions of "RealtimeThreads"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 127: Line 127:
 
* WFNP cannot be used because that only works with Periodic Parameters.  
 
* WFNP cannot be used because that only works with Periodic Parameters.  
 
* Programmer needs to provide his own mechanisms.
 
* 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.
+
* '''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.
 
* Indeed, programmers are best advised to use Async Event handlers to represent non-periodic activities.

Revision as of 09:51, 1 January 2012

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.
  • 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.

DL Miss

  • 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
    • Misscount is decremented.
    • If lastreturn is false - then a previous DL has been missed as well and the current DL too because missCount > 0
      • PendingRelease decremented, and false returned again. (next release has already missed its DL ) - TODO
    • Else last return is not false - previous release has not missed its DL. But to indicate current DL is missed, false is returned.
  • 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.

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. [TODO: But isnt RTThread automatically blocked-for-reschedule when DL miss happens and a DL Handler is defined ?]

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.