TDDD82 Secure Mobile Systems Systems Software Lecture 2: Mutual exclusion,

TDDD82

Secure Mobile Systems

Systems Software

Lecture 2: Mutual exclusion,

Semaphores & Monitors

Mikael Asplund

Real-time Systems Laboratory

Department of Computer and Information Science

Linköping University

Based on slides by Simin Nadjm-Tehrani

Project course TDDD82

Systems software module

42 pages

From last lecture

• How did it go with the exercise?

Process P1

X = 3;

Y = 0;

If (Y > 1) {

X = X - 1

} else {

X = X + 2

}

Process P2

X = 3;

Y = 2;

If Y < 1 {

X = X + 1

} else {

X = X – 2

}



2 of 42

Lecture 1-3 Topics

• Processes, threads, and their representation

• Concurrency and execution

• Communication

• Synchronisation

• Solutions to mutual exclusion problem (ME)

• Support in operating system: semaphores

• Support in runtime system: monitors

• Deadlock and related issues



3 of 42

Atomic update & ME

• Atomic: an operation that is always performed without interruptions

• To ensure that a single process updates a shared (complex) data structure at any time the application needs to manage the mutual exclusion problem!



4 of 42

Mutual exclusion

• Consider n processes that need to exclude concurrent execution of some parts of their code

Process Pi {

entry-protocol

critical-section

exit-protocol

non-critical-section

}

• Fundamental problem to design entry and exit protocols for critical sections



5 of 42

Process A while true {

…

X = X+1

Z = X^2

…

}

Critical section: example

Process B while true {

… if ((X mod 2)==0){

print(X)

}

print(Z)

…

}



6 of 42

First attempt

Process P1 while true {

flag1 = up while (flag2 == up) {

do nothing (* busy waiting *)

}

critical-section

flag1 = down


}



[Dijkstra 1965]

7 of 42


} while (flag2 == up) {

do nothing (* busy waiting *)

flag1 = up

critical-section

flag2 = down


}

Second attempt



8 of 42

Process P1 while true { while (turn == 2) {

do nothing (*busy waiting*)

}

critical-section

turn = 2


}



Third attempt

9 of 42

Process P1 while true { flag1 = up turn = 2 while (flag2 == up) and

(turn == 2) {

do nothing

} critical-section flag1 = down non-critical-section

}

Peterson’s algorithm


flag2 = up

turn = 1 while (flag1 == up) and

(turn == 1) {

do nothing

}

critical-section

flag2 = down


}



10 of 42

Peterson’s algorithm

1A

1B

1C

Process P1 while true { flag1 = up turn = 2 while (flag2 == up) and

(turn == 2) {

do nothing

} critical-section flag1 = down non-critical-section

}

2A

2B

2C


flag2 = up

turn = 1 while (flag1 == up) and

(turn == 1) {

do nothing

}

critical-section

flag2 = down


}



11 of 42

Summary of early solutions

• Implementing synchronisation and concurrency with shared variables, using only sequential programming constructs, is difficult and error prone

• Busy waiting solutions to mutual exclusion problems are:

– Difficult to implement - consider n processes instead of 2 in the Peterson solution!

– Wasteful for the CPU as a resource

• But...

– They do not require any support



12 of 42

Programming language support

• Would be useful to have support from an operating system or a programming language

• Some programming languages have explicit support:

– Java: Early versions used Suspend/Resume constructs that led to race condition!

– Now java.util.concurrency provides good support.

– Ada: built-in run-time support with explicit task synchronisation entry points (Rendezvous)



13 of 42

Next: more support

• How can the mutual exclusion and synchronisation problems be solved with other constructs?

– Semaphore and monitor

• What do we gain by using the support in

OS or programming language?



14 of 42




• Communication

• Synchronisation

• Solutions to mutual exclusion problem (ME)






15 of 42

Recall from last lecture

Two general problems:

• Mutual exclusion

Process Pi { entry-protocol critical-section exit-protocol non-critical-section

}

• Condition synchronisation

Ex: Compute the interest when all cashpoint transactions have been processed



16 of 42

Semaphores

• A semaphore S is a non-negative integer variable on which only two operations wait and signal can be performed wait (S) if S > 0 then S = S-1 else suspend the process calling wait(S) signal (S) if some process P has been suspended by an earlier wait(S), then wake up P else S = S+1



17 of 42

Process Pi var mex: semaphore (* initially 1 *) while true {

wait(mex)

critical_section

signal(mex)

non_critical_section

}

Mutual exclusion



18 of 42

Food for thought

Questions:

• How does the program behave with initial value 0 for the semaphore?

• If there are two processes, what is the maximum value of mex?

• If there are n processes?



19 of 42

Counting semaphores

• When more than one instance of a resource is available, e.g. print servers

• Processes can use up to max available but no more

• The semaphore can be initialised to provide access for n processes



20 of 42

Recall: two general problems

●

Mutual exclusion

Process Pi { entry-protocol critical-section exit-protocol non-critical-section

}

• Condition synchronisation

Ex: Compute the interest when all cashpoint transactions have been processed



21 of 42

Condition synchronisation var condition:semaphore (* initially 0*) process P1 (* waiting process *)

...

wait (condition)

...

process P2 (* signalling process *)

...

signal (condition)

...



22 of 42

Semaphore implementations

• Wait and Signal are implemented (by the operating system) as atomic operations

• Semaphore variable is always initialised as non-negative

But

• Which process to wake up among all suspended ones is not specified



23 of 42

Atomicity: alternatives

• For programmer wait and signal are atomic (indivisible) operations

• In the supporting environment:

– allowing only one wait/signal to operate on a semaphore at any one time e.g. by

See

Siberschatz

Chapter 6.4

• disabling interrupts during execution

• busy waiting on entry to semaphore 

• hardware support (e.g. test-and-set operations) for locking before wait/signal



24 of 42

Semaphore implementations

• Wait and Signal are implemented as atomic operations

• Semaphore is always initialised as nonnegative

But

• Which process to wake up among all suspended ones is not specified



25 of 42

Queue implementations

Process P1

… wait

…

(s) signal (s)

…

Process P2

… wait (s)

… signal (s)

…

One queue/semaphore at run-time:



Process P3

… wait (s)

… signal (s)

…

26 of 42

Originally: Spin locks

• The original definitions of wait & signal just used a version of busy waiting to implement the semaphore: wait (s): while s ≤ 0 do nothing;

s = s-1 signal (s): s = s+1



27 of 42

Semaphores vs. Busy waiting

• For long critical sections, semaphores

(that use a queue) more efficient in using CPU

• Better code organisation, less errors?

• What about problems with deadlock and starvation?

• We will come back to these ...



28 of 42

Before next lecture: Exercise

Process A Process B while true { while true {

print(A) print(T)

print(K) print(C)

} }

Insert semaphores so that a sequence of

“TACK”s is printed out.



29 of 42




• Communication

• Synchronisation

• Solutions to mutual exclusion problem






30 of 42

What is a monitor?

• A programming abstraction consisting of:

– A data structure on which programmer can define operations – which can only be run one at a time

– Condition variables for synchronisation

• Encapsulates shared data that several processes can operate upon

• All access is with mutual exclusion

• Pre object-orientation!

[Hoare 74]



31 of 42



Shared data

Condition variables X, Y

Operations on

Shared data

Initialisation code

Overview

32 of 42

Condition variables

•

• Declared as special synchronisation variables:

Condition X;

With two designated operations:

Don’t mix up these operations with Semaphore operations!

wait (X): suspend the calling process signal (X): if there are suspended processes on this variable, wake one up



33 of 42

Example: Bounded buffer

(* in some language that supports monitors *) monitor BoundedBuffer {

Buf: array [0..SizeOfBuffer] of integer

Base, Top: integer

Count: integer

NotFull, NotEmpty: condition

operation Append(E: integer ) {

...

}

operation Take(E: integer ) {

...

}

begin

<initialize> (* set Base,Top,Count to 0 *)

}



34 of 42

operation Append (E: integer ) {

if ( Count == SizeOfBuffer + 1) {

wait (NotFull)

}

Buff[Top] = E

Top = (Top + 1) mod SizeOfBuffer

Count = Count + 1

signal (NotEmpty)

}

Operation Append



35 of 42

operation Take (E: integer ) {

if (Count == 0) {

wait (NotEmpty)

}

E = Buff[Base]

Base = (Base + 1) mod SizeOfBuffer

Count = Count - 1

signal (NotFull)

}

Operation Take



36 of 42

Producer-Consumer problem

Process Producer var Element: integer while true {

Produce(Element)

Append(Element)

}

Process Consumer var Element: integer while true {

Take(Element)

Consume(Element)

}



37 of 42

Observations

• Programmer uses wait and signal inside the code that applies the operations on the shared data structure

Note:

• The condition variable has no values assigned to it

• The queue associated with each variable is the main synchronisation mechanism

• Different semantics from semaphore operations for wait and signal



38 of 42

Process queues

Queue of processes wanting to execute some monitor operation

These operations may use wait/signal on X, Y

Shared data

Condition variables X, Y

X:

Y: queue of processes waiting for X queue of processes waiting for Y

Operations on

Shared data

Initialisation code



39 of 42

How does it work?

Process P1

… wait(X)

Process P4

… signal(X)

Process P2

… t

Which process to run at time t?


Systems software module time

40 of 42

Options

• Original Hoare monitor: let the woken up process (P1) continue

What if there are several processes waiting on X?

• Pragmatic solution (Java): let the signalling process continue, and wake up P1 once P4 is suspended/exits

P1 has to check for condition X when woken up!



41 of 42

Summary

• Monitors have the same goal as semaphores but are at a higher level of abstraction

– Exercise: Try implementing producerconsumer solution with semaphores!

• Monitor has two different mechanisms, one for handling synchronisation and one for data sharing

• Mutually exclusive access to data is automatic, but matching waits and signals still a problem!



42 of 42

Android concurrency

• Uses java concurrency library

• One Linux process per application

–

One or more threads

–

Used for background tasks

UI thread

BG BG BG



43 of 42

Android thread communication

• Message passing!

• UI thread runs a Loop that processes messages

Invoke message handler for M1

M1

M2

M3

M4

M5



44 of 42

Java concurrency

• Low level basic notions:

–

–

–

– java.lang.Thread

volatile synchronized

Object.wait(), Object.notify()

• Not so easy to use!



45 of 42

Java high level concurrency

• java.util.concurrency

–

–

–

Semaphores

Executor

Concurrent data structures

• For example, bounded buffer:

– java.util.concurrent.ArrayBlockingQueue<E>



46 of 42



–

–



• Avoid using these directly



47 of 42



–

–



• Avoid using these directly



48 of 42

TDDD82 Secure Mobile Systems Systems Software Lecture 2: Mutual exclusion,

Related documents

Products

Support

TDDD82 Secure Mobile Systems Systems Software Lecture 2: Mutual exclusion,

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib