1. 1 Fundamentals of Concurrent Systems  Fundamentals of Concurrent Processes The issues to be addressed here are:  1. Process and Thread  2. Fine-Grained Atomic Actions and Coarse Grained Atomic Actions  3. Program properties  4. Safety properties  5. Liveness Properties  6. Getting Desirable Properties

2. Fundamentals of Concurrent Systems n Process and Thread  Process. A process is an instance of a running program that is isolated from other processes on the same machine. In particular, it has its own private section of the machine’s memory. s Just like computers connected across a network, processes normally share no memory between them. s A process can’t access another process’s memory or objects at all. s By contrast, a new process is automatically ready for message passing, because it is created with standard input & output streams, which are the System.out and System.in streams in Java.  Thread. A thread is a locus of control inside a running program 2 When there are more threads than processors, concurrency is simulated by time slicing, which means that the processor switches between threads. The figure on the right shows how three threads T1, T2, and T3 might be time-sliced on a machine that has only two actual processors.

3. Fundamentals of Concurrent Systems n Thread-safe  A statement or method is thread-safe if it behaves correctly when used from multiple threads, regardless of how those threads are executed.  For example the Java Iterator class is not thread-safe.  Iterator’s specification says that you can’t modify a collection at the same time as you’re iterating over it.  Confinement  Our first way of achieving thread safety is confinement where you don’t give any other threads the ability to read or write the data directly.  Local variables are always thread confined. A local variable is stored in the stack, and each thread has its own stack.  Immutability  Immutability achieves thread safety by allowing you to only read the variable, not write it. Be careful, because this safety applies only to the variable itself, and we still have to argue that the object the variable points to is immutable.  Store shared mutable data in existing thread-safe data types  When a data type in the Java library is thread-safe, its documentation will explicitly state that fact. For example, StringBuffer is Thread-safe. 3

4. Fundamentals of Concurrent Systems n Fine Grained Atomicity H An atomic action makes an indivisible state transformation (any intermediate state that may exists on the implementation must not be visible to another process) H A fine-grained atomic action is one that is implemented directly by the hardware on which a concurrent program executes. H In sequential programs, assignment statements appear to be atomic (no intermediate state is visible to the program. In concurrent programs this is generally not the case: 4 Int y=0, z=0; co x=y+z; // y=1; z=2; oc Assume: Reading and writing variables are fine-grained atomic actions If x=y+z is implemented by loading a Register with y and then adding z to it, The final value of x could be: 0,1,2,3 If x=y+z is implemented by loading a Register with y and then adding z to it, The final value of x could be: 0,1,2,3

5. Fundamentals of Concurrent Systems n We Assume that machines have the following realistic characteristics: H Values of the basic types are stored in memory elements that are read and written as atomic actions H Values are manipulated by loading them into registers, operating on them there, then storing the result back into memory H Each process has its own set of registers. (realized by having distinct sets of registers or by saving and restoring register values whenever a different process is executed). H Any intermediate results that occur when a complex expression is evaluated are stored in registers or in memory private to the executing process (e.g. a private stack). 5

6. Fundamentals of Concurrent Systems n With this model, if an expression e in one process does not reference a variable altered by another process, expression evaluation will appear to be atomic, even if it requires executing several fine-grained atomic actions n This is because: H None of the values on which e depends could possibly change while e is being evaluated and H No other process can see any temporary values that might be created while the expression is being evaluated n Similarly, if an assignment x=e in one process does not reference any variable altered by another process, then the execution of the assignment will appear to be atomic 6

7. 7 Fundamentals of Concurrent Systems  Unfortunately, most statements in concurrent programs that reference shared variables do not meet the above disjointness requirement. However a weaker requirement is often met.  At-Most-Once Property  An expression e = e(x, y,...) satisfies the at-most-once (amo) property if it contains at most one simple variable y which can be changed by another process and if e refers to y at most once.  Examples for amo compliance? (hence making them atomic actions)  (i) (x + 3y) *z + 5w (z can be altered by another process)  (ii) (x + 3y) * x + 5w (x can be altered)  (iii) (x + 4y) * z + 5w (both x and w can be altered by some other  process) Atomic NOT Atomic

8. 8d Fundamentals of Concurrent Systems  An assignment statement x = e(y, z,...) satisfies amo if (a) e satisfies amo and x isn't read by any other process, or, (b) x is a simple variable and e doesn't refer to any variable that can be changed by any other process  Examples Decide if the following are amo: (i) x = a + b (another process can write a) (ii) s = s + 1 (another process can read s, and another process can write s) (iii) x = e(y, z...) (e satisfies amo but x is read by another process)  Amo Assignments are Atomic If an assignment action satisfies the At-Most-Once property then it is an atomic action. Example X=3*Y+Z (a)X not read by another process then either Y or Z can be changed and still satisfy amo (b) If Y and Z not changed by another process then X can be read and still satisfy amo Yes No Yes if x is a simple variable

9. Fundamentals of concurrent systems n A few more examples – do they satisfy the amo property? 9 int x=0, y=0; co x=x+1; // y=y+1; oc int x=0, y=0; co x=y+1; // y=y+1; oc int x=0, y=0; co x=y+1; // y=x+1; oc No critical references in either process, final value of x and y are both 1;  satisfies amo S1 references y (one critical ref), but x is not read by S2 and S2 has no critical references.  Both assignments satisfy the property S1 references y (one critical ref), but x is not read by S2 and S2 has no critical references.  Both assignments satisfy the property Neither assignment satisfies the amo: The expression in each process contains a critical reference and Each process assigns to a variable read by the other. Neither assignment satisfies the amo: The expression in each process contains a critical reference and Each process assigns to a variable read by the other.

10. Fundamentals of concurrent systems Specifying Synchronization n If an expression or assignment statement does not satisfy the amo property, we often need to have it executed atomically n More generally, we often need to execute sequences of statements as a single atomic action. n In both cases, we need to use a synchronization mechanism to construct what is termed a coarse-grained atomic action 10

11. Fundamentals of concurrent systems Examples of Synchronization n A database contains two values, X and Y, and that at all times they are to be the same in the sense that no process examining the database is ever to see a state in which X and Y differ 11 If a process alters X, it must alter Y as part of the same atomic action

12. Fundamentals of concurrent systems n A process inserts elements on a queue represented as a linked list. Another process removes elements from the list, assuming there are elements on the list. One variable points to the head of the list and another to the tail of the list H Inserting and removing elements require the manipulation of 2 variables H If the list contains just one element, simultaneous insertion and removal can conflict leaving the list in an unstable state. 12 Insertion and Removal must be atomic actions If the list is empty, we need to delay the execution of a remove operation until an element has been inserted

13. 13 Fundamentals of Concurrent Systems  Coarse-Grained Atomic Actions  Definition A coarse-grained atomic action is a sequence of fine-grained atomic actions which appears to be indivisible.  A coarse-grained atomic action is a high-level specification of required program behaviour which may be implemented in various ways, depending on the synchronisation mechanisms available within a programming environment.  await The await statement has the form:  await B S;  Boolean expression B is called the delay condition or guard. S is a sequence of sequential statements that is guaranteed to terminate. The angle brackets indicate that await is atomic. B is guaranteed to be true when S begins and no internal state in S is visible to other processes. Atomic Action < S1; S2; S3; > Angle Brackets indicates that these three statements are ATOMIC

14. 14 Fundamentals of Concurrent Systems  Example using await  await (s > 0) s = s - 1;  This atomic action delays until s is positive then decrements s. No other process can sneak in and change s in the meantime.  await (u = =5 and w = =3 and x < 0) x = 1; z = (a + u) * (b + w);   Mutual Exclusion (just leave out await ) Specified with just: Example:  x = z; y = a; z = a + x;   Condition Synchronisation using await Just wait till the Boolean condition holds:  await ( x ==z and y == a and z == a + 2)  Angle Brackets indicates that this is an ATOMIC action Causes process to wait until condition is true

15. 15 Fundamentals of Concurrent Systems  Unconditional Atomic Action (used to specify mutual exclusion) This is an await statement without a guard: Example  x = z; y = a; z = a + x   Conditional Atomic Action This is an await statement with a guard:  await (B) S;   Program Properties A property of a program is a statement about the program which is true for all execution histories. In other words, no matter what actual statements get executed in a particular run of a program, the statement still holds true.  Example: The property Nroom  0 holds for all execution histories of Porter program. e.g. 0) x = x-1; >

16. 16 Fundamentals of Concurrent Systems  Safety Properties A safety property H, of a concurrent program CP is an assertion that something bad never happens. Example: (three safety properties) H1: Never (number of trolleys in treatment room more than one.) H2: Never (Nroom <0) H3: Never (Nroom >4)  Liveness Properties A liveness property of a concurrent program CP is an assertion that something good eventually happens. An example might be the assertion that the program terminates. l For the concurrent program Porters we might have the assertion: L1: Ward porter drinks tea If Nroom goes above four then something bad has happened i.e. too many patients in treatment room If porter never gets to drink tea then something has gone wrong! In programs this means that it failed to terminate

17. 17 Fundamentals of Concurrent Systems  Getting Desirable Properties  1. The Ostrich Approach Write the program, run a few tests with trial data.  NOT ADVISABLE FOR CRITICAL SYSTEMS  2. The Operational Approach Examine all possible histories of the program.  NOT FEASIBLE  3. The Assertional Approach Prove that desired properties hold.  SAFER THAN OSTRICH AND SHORTER THAN OPERATIONAL APPROACH, BUT STILL QUITE TIME CONSUMING Only proves the program works in the test cases Too much work as there can be a large number of histories Semi-mathematical approach to prove the correctness of a program

18. 18 Fundamentals of Concurrent Systems  The Assertional Approach  State Assume that at any one moment during the execution of a program, a computer system can be described by a collection of variables known as its state. These will be the contents of memory variables and registers and also of program counters, stack pointers and so on.  A program statement acts on a given state and produces a new state.  Predicate A predicate is a sentence about a state expressed in mathematical terminology. A predicate can be true or false concerning a given program state.  Action An action is the execution of a program statement. It changes the state of the system, and so can affect the truth of predicates. e.g. (Nroom < =4) State1 State2 statement T <400 T <=400 T = T+1

19. 19 Fundamentals of Concurrent Systems  Triples A triple is a formula of the form: {P} S {Q} The interpretation of a triple is as follows.  P is a predicate known as the pre-condition.  S is a simple or compound programming statement.  Q is a predicate known as the post-condition.  The triple is true whenever execution of S is begun in a state satisfying P and when execution of S terminates then the resulting state satisfies Q.  P and Q are often called assertions.  Examples: { x = =1 } x = x + 1; { x= = 2 } { x > 0 } x := x - 1; { x >= 0 } { x == 0 } x = x - 1; { x < 0 } P QS

20. 20 Fundamentals of Concurrent Systems  Safety Properties and Triples A safety property H, of a program GP is one for which the triple { H } S i { H } is always true no matter what program statement S i of GP is executed. This means that if the safety property was true before the program was executed then it will be true at any stage of program execution.  Liveness Property A property, L, is a liveness property for the concurrent programme CP if for any possible execution history of the program: S i1, S i2,... S ij then there is some point S ij in that execution history at which the property is true: S i1, S i2,... S ij {L} In a process or program this means that the execution reaches some desired point. It can be the end point.

21. 21 Fundamentals of Concurrent Systems  Liveness Properties  Liveness properties ensure that a request for service will be honoured eventually.  The scheduling policy of the underlying operating system affects liveness. Example : Will this program terminate? boolean continue = true; co while (continue) skip; // continue = false; oc P2 If P2 starts first then the overall program terminates If P1 starts first then the overall program MAY terminate! Note. If P1 goes first and the operating system uses PREMPTIVE scheduling (i.e. CPU time slicing) then the program will terminate – otherwise no. P1 Note. Either process P1 or P2 can start executing first – depending on how the operating system schedules them loop

22. Fundamentals of Concurrent Systems n Most liveness properties depend on fairness, which is concerned with guaranteeing that processes get the chance to proceed, regardless of what other processes do n Each process executes a sequence of atomic actions n An atomic action in a process is eligible if it is the next atomic action in the process that could be executed (when there are several processes there are several eligible atomic actions) n A Scheduling policy determines which one will be executed next. 22

23. 23 Fundamentals of Concurrent Systems  Three Classes of Fairness  Unconditional fairness,  Weak fairness,  Strong fairness  1. Unconditional Fairness A scheduling policy is unconditionally fair if every unconditional atomic action that is eligible is eventually executed.  Co-operative multitasking is not unconditionally fair on a single processor.  Round-robin scheduling is unconditionally fair on a single processor.  Parallel execution of any type is unconditionally fair on a multiprocessor (provided that there are fewer programs than processors).  Will the example program above terminate with unconditional fairness? (with regard to the operating system scheduling policy) These scheduling policies can affect whether the program will terminate Co-operative multitasking is a type of multitasking in which the process currently controlling the CPU may offer control to other processes is called cooperative because all programs must cooperate for it to work. If one program does not cooperate, it can hog the CPU. In contrast, preemptive multitasking forces applications to share the CPU. Yes

24. 24 Fundamentals of Concurrent Systems  2. Weak Fairness A scheduling policy is weakly fair if it is unconditionally fair and every conditional atomic action, that is eligible is executed eventually, assuming that its condition becomes true and then remains true until it is seen by the process executing the conditional atomic action  (Case where B stays true is weakly fair)  Round-robin is weakly-fair. int i = 0; boolean continue = true; co while(continue) i = 1; // oc P1 P2 Terminates under Weak Fairness using Round Robin scheduling Round-robin and time slicing are weakly fair scheduling policies if every process gets a chance to execute. Weak Fairness is not sufficient to ensure that any eligible await statement eventually executes

25. 25 Fundamentals of Concurrent Systems  3. Strong Fairness A scheduling policy is strongly fair if it is weakly fair and also if every conditional atomic action which becomes eligible is eventually executed if its guard is infinitely often true: int i = 0; boolean continue = true; co while(continue) { i = 1; i = 0; i = -1; } // oc P1 P2 Note. The guard (i==0) is infinitely often true A condition is infinitely often true if it is true an infinite number of times in every execution history of a (nonterminating) program

26. 26 Fundamentals of Concurrent Systems  The above example will terminate with strongly fair scheduling but not with weakly fair scheduling. Why?  Implementation It is not possible to devise a general processor scheduling policy that is both strongly fair and practical. Consequently operating systems can only be relied upon to support weak fairness. However this is sufficient for systems developed using most concurrent programming languages. The guard is true some of the time, which is sufficient for strong fairness, but needs to remain true to satisfy weak fairness

27. 27 Fundamentals of Concurrent Systems n Revision Questions In order to bake a cake the two partners Mary and Elinor must complete the following actions. M1: sift flour and spices E1: cream butter and sugar E2: mix flour with butter and sugar M2: chop fruit. M3: add milk to four, butter and sugar E3: add chopped fruit to mixture (a) Assume that the global variables done_m1, done_e1, etc. are used to define the end of each activity. They are all false initially. Write down two pseudo- programs - one for Mary and one for Elinor, in which each person must wait for certain actions to complete. Use the notation for coarse-grained atomic actions here. (b) Now assume that M1 and E1 include the extra program activity:: use sink. Define a shared variable sink_free, and then define two coarse-grained atomic actions. The first action has a cook wait till sink_free is true, then sets sink_free to false. The second action sets sink_free to true.

28. 28 Fundamentals of Concurrent Systems n Topics addressed:  Thread and Process  Fine-Grained Atomic Actions and Coarse Grained Atomic Actions  Program properties  Getting Desirable Program Properties  Safety properties  Liveness Properties  Classes of Fairness in a scheduling policy