IT606 Embedded Systems Software A Primer on Concurrency

IT-606 Embedded Systems (Software) A Primer on Concurrency Krithi Ramamritham S. Ramesh Kavi Arya KRe. SIT/ IIT Bombay © S. Ramesh / Krithi Ramamritham / Kavi Arya 1

Embedded Systems? © S. Ramesh / Krithi Ramamritham / Kavi Arya 2

Concurrency Models • ES are concurrent systems • Environment and System evolve simultaneously • ES often decomposed into subsystems that evolve concurrently • Concurrent systems are more complex • Clear understanding essential © S. Ramesh / Krithi Ramamritham / Kavi Arya 3

Sequential Models A program consists of a sequence of instruction I 1; I 2; I 3; ……In • Execution starts with I 1 • After I 1, I 2 is executed and so on • Constructs for altering the control like – Branches – Loops – exits and goto © S. Ramesh / Krithi Ramamritham / Kavi Arya 4

Concurrent Programs • A concurrent program consists of two or more processes • Each process is a sequential program • `threads' or `processes' Example: cobegin x=5 y = 10 Coend • z = 23 Various other notations like parbegin-parend, fork-join, create-kill etc © S. Ramesh / Krithi Ramamritham / Kavi Arya 5

Concurrent Execution Concurrent execution involves, • Sequentially executing each process • Interleaved execution model – any process executed at any time – any number of instructions from a process – arbitrary relative speeds • This is a conceptual model • In reality, simultaneous execution possible • useful for analysis and understanding © S. Ramesh / Krithi Ramamritham / Kavi Arya 6

Example execution • • • x, y and z updated to 5, 10 and 23 respectively Updation takes place in any order Not necessarily the textual order Final result independent of execution order Not true, in general © S. Ramesh / Krithi Ramamritham / Kavi Arya 7

Nondeterminism • Same input, different execution - different results • Nondeterminism Example cobegin printf ("Hello world!n"); printf ("How are you? n"); printf ("What is your name? n"); coend © S. Ramesh / Krithi Ramamritham / Kavi Arya 8

Nondeterminism Some of the Possible results are: 1. Hello World! How are you? What is your name? 2. How are you? What is your name? Hello World! 3. What is your name? Hello World! How are you? What are the other possibilities? © S. Ramesh / Krithi Ramamritham / Kavi Arya 9

Speed Independence Result of concurrent execution • Depends upon speed of execution • But this is undesirable, in general • Write programs that computes the same irrespective of relative speed of execution • There are cases, when we do not mind indeterminacy – Server responses to client processes – Order of printing of user files © S. Ramesh / Krithi Ramamritham / Kavi Arya 10

Speed Independence • How to reconcile determinism with concurrency? – Classical approach (here) – Synchronous approach (later) • Compare the two examples • Result is deterministic in the first case • Why? © S. Ramesh / Krithi Ramamritham / Kavi Arya 11

Independent Processes • • In the first example, no sharing of variables In the second one, no explicit sharing Implicitly printer buffer is shared Whenever there is sharing, results may be nondeterminstic • Conclusion: Avoid implicit or explicit sharing of variables • But is that a solution! © S. Ramesh / Krithi Ramamritham / Kavi Arya 12

Independent Processes • Too restrictive • Concurrent processes need to communicate to perform some collective function • Communication is essential • Need special mechanism to ensure determinacy • Synchronization Primitives © S. Ramesh / Krithi Ramamritham / Kavi Arya 13

Communication & Co-operation Two means of communication • Sharing of variables – Common variables across processes – Reading and writing by different processes – Most often used in processes in single systems • Message passing – One process sends a message and another receives – No sharing of variables – used in distributed systems © S. Ramesh / Krithi Ramamritham / Kavi Arya 14

Shared Variable Concurrency Simple examples: cobegin x = 0; x = x + 1; coend x = 1; x = x+1 What is the value of x at the end? • 1, 2 ? • 3? • Is 0 possible? © S. Ramesh / Krithi Ramamritham / Kavi Arya 15

Atomicity How is 0 possible? • Interleaving of steps of processes • What is a step? • A single statement in the high level language? • An instruction in the machine language? • It can even be more primitive action: • Reading / writing a bit / byte © S. Ramesh / Krithi Ramamritham / Kavi Arya 16

Atomicity A consequence • Programmer should know what the steps are? • Steps would depend upon machines • For machine independent behaviour • Better that individual steps are specifed by the programmer Atomic actions are • Atomic! • No substeps - no interleaving • Basic actions in a machine • Typically, read and write actions © S. Ramesh / Krithi Ramamritham / Kavi Arya 17

Another Example • Producer Consumer Problem - to be filled up ? © S. Ramesh / Krithi Ramamritham / Kavi Arya 18

Correctness of the solution • • • Is the solution correct? Consider this scenario Concurrent execution of count assignments Lead to incorrect results They should be executed atomically © S. Ramesh / Krithi Ramamritham / Kavi Arya 19

Synchronization mechanisms • One of the Simplest high level mechanism • Programs indicates atomic actions • Specified atomicity can include one or more statements Example: Cobegin ! x = 0; x = x + 1; x = 0 ; x = x + 1 Coend What will be the value of x at the end? © S. Ramesh / Krithi Ramamritham / Kavi Arya 20

Modified Producer-Consumer solution © S. Ramesh / Krithi Ramamritham / Kavi Arya 21

Semaphores are • Special non negative variables • Allows two basic operations • Signal and Wait • Signal(x) - increments the x • Wait(x) - decrements if x ? 0 • Wait(x) suspends the process when x = 0 • Both are atomic operations © S. Ramesh / Krithi Ramamritham / Kavi Arya 22

Producer - Consumer Problem • Semaphore based solution © S. Ramesh / Krithi Ramamritham / Kavi Arya 23

Implementation • • How do you ensure atomicity? How does the waiting process know that it can proceed Which processes are waiting Concerns of implementation - at the high level make assumptions • Scheduler-based implementation – maintains status of processes – queue of waiting processes – schedules different processes at different time – program behaviour independent of scheduler © S. Ramesh / Krithi Ramamritham / Kavi Arya 24

Problems with concurrency Deadlocking Consider: • P 1 waits for P 2, P 2 waits for P 3 • P 3 waits for P 1 • Circular wait, no progress • Deadlock • New kind of error © S. Ramesh / Krithi Ramamritham / Kavi Arya 25

Starvation Consider the following problem: cobegin while (y ? 0) x = x + 1; y=0 coend • • • Assume the initial value of y? 0 Will the program terminate ? Need not terminate, in theory – First process can keep executing • • Terminates in practice Fairness in selection of processes Examples in which some processes may not progress even with fairness Additional problems due to concurrency and synch. primitives © S. Ramesh / Krithi Ramamritham / Kavi Arya 26

Conspiracy – Examples © S. Ramesh / Krithi Ramamritham / Kavi Arya 27

Message Passing Concurrency Processes • do not share variable • share channels instead • channels carry messages • send and receive actions • asynchronous communication • handshake communication • receiver waits till sender sends a message • sender waits when the channel is full • guarded wait actions • Languages like CSP, Promela, Handel-C © S. Ramesh / Krithi Ramamritham / Kavi Arya 28

Alternating bit Protocol © S. Ramesh / Krithi Ramamritham / Kavi Arya 29

Problems • Deadlock, livelock, conspiracies possible • fairness assumption required Example: A deadlocking program © S. Ramesh / Krithi Ramamritham / Kavi Arya 30

Summary • • • A very brief introduction Concurrent processes Interleaved execution model Primitives for synchronization Design Problems – Nondeterminism, Deadlocks, livelocks and Conspiracies © S. Ramesh / Krithi Ramamritham / Kavi Arya 31

Summary Classical Concurrency Model • It is an asynchronous model • No upper-bound on waiting time • No guarantee on execution of atomic actions • Very little control on timing • System behaviour unpredictable, espcially under revision • gives serious problems for real-time applications © S. Ramesh / Krithi Ramamritham / Kavi Arya 32