Relationship to Textbook

• This lecture is partially based on material in Chapter 1 of the Magee & Kramer textbook
• More info on “the two Jeffs”
  • Jeff Kramer
    • Dean of the Faculty of Engineering and Professor of Distributed Computing at the Department of Computing at Imperial College London
    • ACM Fellow
    • Editor of IEEE's Transactions on Software Engineering
    • Winner of numerous software engineering awards including best paper and outstanding research awards
  • Jeff Magee
    • Professor in Computing at the Department of Computing at Imperial College London
    • Long time member of the software engineering community with more than 70 journal and conference publications!

What is a Concurrent Program?

• A sequential program has a single thread of control

• A concurrent program has multiple threads of control

• A concurrent program can perform multiple computations in parallel and can control multiple external activities which occur at the same time
• One difficulty with programming concurrent programs is dealing with the places in the code in which multiple threads of control intersect

Why is this hard?

• The multiple threads of a single program can encounter shared memory interactions in which two or more threads read/write the value of a shared memory location (i.e. variable)
  • If this is not done correctly, the value of the variable can become meaningless as it is modified by multiple threads simultaneously
• A similar situation occurs in a distributed setting when multiple clients encounter network interactions when interacting with a single server

Benefits of Concurrent Programming

• Performance gain from multiprocessing hardware
  • parallelism
• Increased application throughput
  • an I/O call need only block one thread
• Increased application responsiveness
  • high priority thread for user requests
• More appropriate structure
  • for programs which interact with the environment, control multiple activities, and handle multiple events

Concurrent Programming is Becoming Hard to Ignore

• Multi-Core Chips are starting to become widely deployed
  • Only multi-threaded applications will see the performance benefits that these chips offer
• Programming for the Web often requires concurrent programming (think image loading in Web browsers)
  • Web browsers are also an example of a multi-threaded GUI application
    • without threads the UI would block as information is being downloaded from the net
• Lots of other domains in which concurrency is the norm
  • Embedded software systems
  • robotics
  • "command-and-control"
  • …

BUT…

• while concurrency is widespread it is also error prone
  • Programmers trained on single-threaded programs face unfamiliar problems: synchronization, race conditions, deadlocks, etc.
• Example: Therac-25 computerized radiation therapy machine
  • Concurrent programming errors contributed to accidents causing deaths and serious injuries
• Mars Rover
  • Problems with interaction between concurrent tasks caused periodic software resets reducing availability for exploration

Example: Cruise Control Simulator

• To motivate the need for a rigorous approach to concurrent program design and implementation, lets look at an example
• Requirements for Cruise Control System:
  • Controlled by three buttons: on, off, resume
  • When the car ignition is switched on and the on button is pressed, the current speed is recorded and the system is enabled: it maintains the speed of the car at the recorded setting
  • Pressing the brake, accelerator or off button disables the system. Pressing resume re-enables the system
  • The system has at least two threads: the engine and the cruise control system
• Once implemented: Is the system safe?
• How do you test for all possible scenarios?
  • Is the cruise control system enabled after the engine is switched on and the on button is pressed?
  • Is the cruise control system disabled when the brake is pressed?
  • Is the cruise control system enabled when resume is pressed?
  • What happens if the engine is turned off while the system is enabled? Or, more importantly, what happens when the system is turned on again after this?

Models to the Rescue!

• The answer to this question is to construct a model of the concurrent behavior of the system and then analyze the model
  • This is one benefit of models, they focus on one particular aspect of the world and ignore all others
• Consider the model that is shown on the front of the Concurrency text book
  • The picture shows the image of a real-world train next to a model of that train
  • Depending on the model, you can ask certain questions and get answers that reflect the answers you would get if you asked the real system
  • For instance, the model on the front of the textbook appears to answer questions like
    • What color is the train?
    • How long is the train?
    • How many cars does the train have?
  • But it may be a poor choice to answer such questions as:
    • How heavy is the train?
    • How does it behave if its second car were to derail?
    • What is the train's maximum speed?
    • etc.

Models, continued

• So, in summary, a model is a simplified representation of the real world
  • A model airplane used in wind tunnel tests models only the external shape of the airplane
  • The reduction in scale and complexity achieved by modeling allows engineers to analyze properties of the model
  • The earliest models were physical; modern models tend to be mathematical in nature and can thus be analyzed by computers
• Engineers use models to gain confidence in the adequacy and validity of a proposed design
  • focus on an aspect of interest—concurrency
  • model animation to visualise a behaviour
  • mechanical verification of properties (safety & progress)

Models for Concurrency

• When modeling concurrency, we make use of a type of finite state machine known as a labeled transition system or LTS
• These machines are described textually with a specification language called finite state processes
• These machines can be displayed and analyzed by an analysis tool called LTSA
  • Note: LTSA requires a Java 2 run time system version 1.5.0 or later
  • On Windows and Mac OS systems, you can run the LTSA tool by double clicking on its jar file
  • Note: Its not the most intuitive piece of software, but once you grok it, it provides all of the advertised functionality

Modeling the Cruise Control System

• We won't model the entire system, lets just look at an example
• Given the following specification (written in FSP):

  CRUISE = (engineOn -> RUNNING),
  RUNNING = (speed -> RUNNING | engineOFF -> CRUISE).

• We can generate a finite state machine that looks like this:
  
• And, using the LTSA Animator, we can animate the finite state machine and observe its behavior (see demo in class)
  • Note: using a modeling tool, like LTSA, allows us to understand the concurrent behaviors of systems, like the cruise control system, BEFORE they are implemented
  • This can save a lot of time and money, as it is typically easier to test and evolve a model's behavior than it is to implement the system in a programming language
  • In Figure 1.4 of the textbook, you can see an execution trace of the cruise control system's state machine (note: the full model of the cruise control system is not presented in Chapter 1) and it clearly shows the problem we observed when we ran the cruise control applet

Programming Practice in Java

• Java is
  • widely available, generally accepted and portable
  • provides sound set of concurrency features
• Java is used for all examples, demo programs and homework exercises in the book
  • This is not to say that Java is the ONLY language to support concurrency; many languages have concurrency features built in
• For some examples, “Toy” problems are used, as they exemplify particular aspects of concurrent programming problems!

Summary

• Concepts
  • We adopt a model-based approach for the design and construction of concurrent programs
• Models
  • We use finite state machines to represent concurrent behavior
• Practice
  • We use Java for constructing concurrent programs
• We will be presenting numerous examples to illustrate concepts, models and demonstration programs

Coming Up Next

• Lecture 4: Software Process
• Lecture 5: Processes and Threads