CS452 - Real-Time Programming - Spring 2009

Lecture 28 - History : Controllers

1. Deadlock

2. Livelock (Deadly Embrace)

3. Critical Races

4. Performance

Priority

The hardest thing to get right

• Sizing stacks used to be harder, but now we have lots of memory
• NP-hard for the human brain
• Practical method starts with all priorities the same, then adjusts
• symptoms of good priority assignment
  • The higher priority, the more likely the ready queue is to be empty
  • The shorter the run time in practice the higher the priority

Problems with priority

1. Priority inversion
2. One resource, many clients
3. Tasks try to do too much

Congestion

1. Too many tasks
   • blocked tasks don't count,
   • lowest priority tasks almost don't count
2. Not enough tasks
   • priority doesn't work any more

Layered abstraction are costly

e.g. Notifier -> SerialServer -> InputAccumulater -> Parser -> TrackServer

Hardware

1. Turn on optimization, but be careful
   • There are places where you have done register allocation by hand
2. Turn on caches
   • locking is possible
3. Size & align calibration tables by size & alignment of cache lines
   • linker command script
4. Slowing and stopping
   • each train has a built in velocity profile when stopping
   • you can create your own velocity profile

Hardware for Real-Time

First Generation

1. Big mainframe computers
   • transaction processing
   • try to be fast, but it's up to the human to wait
2. Finite state machine controllers
   • real-time
     • machines don't wait
   • primarily focussed on small scale control
     • washing machines
     • transmissions
     • artillery shells

     This was previously done by special purpose mechanical, clockwork, electric & hydraulic devices

     • continuous control
       • Watt's governor
     • discrete control
       • dishwasher
         • open and close valves
         • turn pump off & on
         • open the soap door
       • espresso machine
     • Immediate ancestors of the computer
   • usually represented as directed graphs with conditions
     • states are nodes
     • edges are transitions
   • simple translation of mechanical hardware to software
     • discrete components, SSI, with program designed into the circuit
   • run on a fixed clock
     • evaluate conditions
     • change state
   • real-time is put in by hand, painfully
     • could be extensively tested

Second Generation

1. Big mainframe computers
   • transaction processing
   • humans still wait, just not as long
2. Mini-computers
   • real-time
   • primarily focussed on large scale control
     • chemical plamts
     • trains
     • telecommunications

     always backed up by physical failsafes

   • extremely rudimentary single threaded operating systems, to support
     • polling loops
     • cyclic execution
   • interrupt service routines without operating system support
   • Multiple tasks, when required, were programmed ad hoc using more than one computer
     • communication managed by hand
     • no explicit support for real-time
   • Unix came into being on a minicomputer
     • as a response to the all-singing, all-dancing operating systems of mainframes
     • many Unix-like descendants
   • DEC was the leading manufacturer
     • RT11 (real-time for PDP11) was the operating system it supplied
       • MS-DOS was a rip-off of RT11
       • second generation via Gary Kildall
     • PDP11 used the first fully-integrated 16-bit CPU on a chip.
     • What were aree the 8-bit CPUs doing?
3. Other tools, such as state charts
   • real-time
   • state machines with states that are Cartesian products
   • focussed on small scale control
     • digital watches
     • traffic lights

     extension of clocked controller

   • program was in ROM
     • called firmware
   • cyclic execution
     • hardware-clocked

Third Generation

1. Multi-CPU servers
   • more or less tightly coupled
   • dominated by RPC and its relatives
2. Micro-computers
   • many (most?) were used in real-time applications
     • point-of-sale systems
     • games
     • telephone switches
   • supported by DOS (still in use!)
   • much ad hoc intercommunication
     • as with mini-computers
3. Micro-controllers
   • including DSPs

Fourth Generation

1. Multi-(multi-core CPUs) called servers
   • communicate and synchronize using shared memory
     • using techniques from CS343

     or using RPC

     • using techniques from CS454
   • multi-core, cache, and shared memory don't play well together
   • performance limited by threading
     • explicit support for threading, e.g. register windows (Sun) increases performance hugely
     • communication still costly
2. Multi-core microprocessors
   • performance strongly hampered by difficulty of multi-threading
   • multi-core, cache, and shared memory don't play well together
3. Stream processors
   • good for SIMD

Return to:

• Bill Cowan's lecture notes for CS452 in Spring 2009
• Bill Cowan's Spring 2009 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page