1 Fundamentals of Concurrent Systems Fundamentals of Concurrent Processes The issues to be addressed here are: 1. Process and Thread 2. Fine-Grained

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

Just like computers connected across a network, processes normally share no memory between them.

A process can’t access another process’s memory or objects at all. 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

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

4

Fundamentals of Concurrent Systems Fine Grained Atomicity

An atomic action makes an indivisible state transformation (any intermediate state that may exists on the implementation must not be visible to another process)

A fine-grained atomic action is one that is implemented directly by the hardware on which a concurrent program executes.

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:

Int y=0, z=0;co x=y+z; // y=1; z=2; oc

Assume:Reading and writing variablesare 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

5

Fundamentals of Concurrent Systems We Assume that machines have the following realistic characteristics:

Values of the basic types are stored in memory elements that are read and written as atomic actions

Values are manipulated by loading them into registers, operating on them there, then storing the result back into memory

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

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

6

Fundamentals of Concurrent Systems 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

This is because: None of the values on which e depends could possibly change while e is being

evaluated and No other process can see any temporary values that might be created while the

expression is being evaluated

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

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)

AtomicNOT Atomic

NOT Atomic

8d

Fundamentals of Concurrent Systems An assignment statementx = 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 ExamplesDecide 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

YesNo

Yes if x is a simplevariable

9

Fundamentals of concurrent systems A few more examples – do they satisfy the amo property?

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 valueof x and y are both 1; satisfies amo

S1 references y (one critical ref), but x is notread 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 referenceandEach process assigns to a variable read by the other.

10

Fundamentals of concurrent systems

Specifying Synchronization

If an expression or assignment statement does not satisfy the amo property, we often need to have it executed atomically

More generally, we often need to execute sequences of statements as a single atomic action.

In both cases, we need to use a synchronization mechanism to construct what is termed a coarse-grained atomic action

11

Fundamentals of concurrent systems

Examples of Synchronization

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

If a process alters X, it must alter Y as part of the same atomic action

12

Fundamentals of concurrent systems 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

Inserting and removing elements require the manipulation of 2 variables

If the list contains just one element, simultaneous insertion and removal can conflict leaving the list in an unstable state.

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

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.

awaitThe 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

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:< S; >Example: x = z; y = a; z = a + x;

Condition Synchronisation using awaitJust wait till the Boolean condition holds: < await B > 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


Unconditional Atomic Action (used to specify mutual exclusion)This is an await statement without a guard: < S; >Example x = z; y = a; z = a + x

Conditional Atomic ActionThis is an await statement with a guard: await (B) S;

Program PropertiesA 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. <await (x>0) x = x-1; >

16


Safety PropertiesA 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 PropertiesA 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.

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


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

Fundamentals of Concurrent Systems The Assertional Approach

StateAssume 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. PredicateA 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 State2statement

T <400

T <=400

T = T+1

19


TriplesA 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

Fundamentals of Concurrent Systems Safety Properties and Triples

A safety property H, of a program GP is one for which the triple { H } Si { H }

is always true no matter what program statement Si 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 PropertyA property, L, is a liveness property for the concurrent programme CP if for any possible execution history of the program:

Si1, Si2, ... Sij

then there is some point Sij in that execution history at which the property is true: Si1, Si2, ... Sij {L}

In a process or program this means that the execution reaches some desired point. It can be the end point.

21


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 terminatesIf 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 Most liveness properties depend on fairness, which is concerned with

guaranteeing that processes get the chance to proceed, regardless of what other processes do

Each process executes a sequence of atomic actions

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)

A Scheduling policy determines which one will be executed next.

23

Fundamentals of Concurrent Systems Three Classes of Fairness

Unconditional fairness, Weak fairness, Strong fairness

1. Unconditional FairnessA 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


2. Weak FairnessA 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

< await (B) S; > (Case where B stays true is weakly fair) Round-robin is weakly-fair.int i = 0;boolean continue = true;co while(continue)

i = 1; // <await(i==1)continue=false;>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 statementeventually executes

25


3. Strong FairnessA 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;cowhile(continue) {

i = 1; i = 0; i = -1; } // <await(i == 0)continue=false; >oc

P1

P2Note. The guard (i==0) is infinitely often true

A condition is infinitely often trueif it is true an infinite number of times in every execution historyof a (nonterminating) program

26


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


Revision QuestionsIn order to bake a cake the two partners Mary and Elinor must complete the

following actions.M1: sift flour and spicesE1: cream butter and sugarE2: mix flour with butter and sugarM2: chop fruit.M3: add milk to four, butter and sugarE3: 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


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

Documents

1 Fundamentals of Concurrent Systems Fundamentals of Concurrent Processes The issues to be addressed here are: 1. Process and Thread 2. Fine-Grained