master-degree-notes/Concurrent Systems/notes/Lezione1.md

A sequential algorithm is the formal description of the behavior of an abstract state machine.

A program is a sequential algorithm written in a programming language.

A process is a program executed on a concrete machine, characterized by its state (values of the registers). If the process follows one single control flow (i.e. one program counter) then it is a sequential process, or thread.

A set of sequential state machines that run simultaneously and interact through shared memory through a shared medium is called concurrency. In a concurrent system there must be something shared.

Advantages of concurrent systems:

• efficiency: run in parallel different stuff
• simplification of the logic by dividing the task in simpler tasks, running them in different processes and combining the results together.

Features of a concurrent system

We can assume many features:

• Reliable vs Unreliable
• Synchronous vs Asynchronous
• Shared memory vs Channel-based communication

Reliable system: every process correctly executes its program

Asynchronous: no timing assumption (every process has its own clock, which are independent one from the other)

Shared medium: A way is through a shared memory area, another way is through message passing. For this part of the course we assume that every process has a local memory but can access a shared part of the memory. We will assume that memory is split into registers (will see later).

For now, we will assume that processes won't fail. We also assume that we have one processor per process. But actually the processor can be a shared resource (more processes than processors).

Synchronization: cooperation vs competition

Definition of synchronization: the behavior of one process depends on the behavior of others.

This requires two fundamentals interactions:

• Cooperation
• Competition

Cooperation

Different processes work to let all of them succeed in their task.

1. Rendezvous: every involved process has a control point that can be passed only when all processes are at their control point: the set of all control points is called barrier.
2. Producer-consumer: two kind of processes, one that produces data and one that consumes them
   • only produced data can be consumed
   • every datum can be consumed at most once

Competition

Different processes aim at executing some action, but only one of them succeeds. Usually, this is related to the access of the same shared resource.

Example: two processes want to withdraw from a bank account.

function withdraw() {
	x := account.read();
	if x ≥ 1M€ {
		account.write(x – 1M€);
	}
}

While read() and write() may be considered as atomic, their sequential composition is not.

!

Mutual Exclusion (MUTEX)

Ensure that some parts of the code are executed as atomic. This is needed in competition but also in cooperation.

Of course, MUTEX is required only when accessing shared data.

Critical section

A set of code parts that must be run without interferences, i.e. when a process is in a certain shared object (C.S.) than no other process is on that C.S..

MUTEX problem

Design an entry protocol (lock) and an exit protocol (unlock) such that, when used to encapsulate a C.S. (for a given shared object), ensure that at most one process at a time is in a C.S. (for that shared object).

We assume that all C.S.s terminate and that the code is well-formed (lock ; critical section ; unlock).

Safety and liveness

Every solution to a problem should satisfy at least:

• Safety: nothing bad ever happens
• Liveness: something good eventually happens

Liveness without safety: allow anything, something good may eventually happen but also something terrible!

Safety without liveness: forbid anything (no activity in the system)

So safety is necessary for correctness, liveness for meaningfulness.

In the context of MUTEX:

• Safety: there is at most one process at a time in a C.S.
• Liveness:
  • Deadlock freedom: if there is at least one invocation of lock, eventually after at least one process enters a C.S.
  • Starvation freedom: every invocation of lock eventually grants access to the associated C.S.
  • Bounded bypass: let n be the number of processes; then, there exists f: N \to N s.t. every lock enters the C.S. after at most f(n) other C.S.s (The process must win in at most f(n) steps).

todo: riscrivere meglio l'ultimo

Both inclusions are strict: Deadlock freedom \not{\implies} Starvation freedom !

Starvation freedom not \implies Bounded bypass Assume a f and consider the scheduling above, where p2 wins f(3) times and so does p3, then p1 looses (at least) 2f(3) times before winning.

Atomic R/W registers

We will consider different computational models according to the available level of atomicity of the operations provided.

Atomic R/W registers are storage units that can be accessed through two operations (READ and WRITE) such that

1. Each invocation of an operation
   • locks instantaneous (it can be depicted as a single point on the timeline: there exist t : OpInv \to R+)
   • may be located in any point between its starting and ending time
   • does not happen together with any other operation (t is injective)
2. Every READ returns the closest preceding value written in the register, or the initial value (if no WRITE has occurred).

Peterson algorithm (for two processes)

Let's try to enforce MUTEX with just 2 processes.

1st attempt:

lock(i) :=
	AFTER_YOU <- i
	wait AFTER_YOU != i
	return

unlock(i) :=
	return

This protocol satisfies MUTEX, but suffers from deadlock (if one process never locks).

2nd attempt:

Initialize FLAG[0] and FLAG[1] to down
lock(i) :=
	FLAG[i] <- up
	wait FLAG[1-i] = down
	return

unlock(i) :=
	FLAG[i] <- down
	return

Still suffers from deadlock if both processes simultaneously raise their flag.

Correct solution:

Initialize FLAG[0] and FLAG[1] to down
lock(i) :=
	FLAG[i] <- up
	AFTER_YOU <- i
	wait FLAG[1-i] = down OR AFTER_YOU != i
	return

unlock(i) :=
	FLAG[i] <- down
	return

Features:

• it satisfies MUTEX
• it satisfies bounded bypass, with bound = 1
• it requires 2 one-bit SRSW registers (the flags and 1 one-bit MRMW registers (AFTER_YOU)
• Each lock-unlock requires 5 accesses to the registers (4 for lock and 1 for unlock)

MUTEX proof

Assume p0 and p1 are simultaneously in the CS.

How has p0 entered its CS? a) FLAG[1] = down, this is possible only with the following interleaving: !

b) AFTER_YOU = 1, this is possible only with the following interleaving: !

Bounded Bypass proof (with bound = 1)

• If the wait condition is true, then it wins (and waits 0).

• Otherwise, it must be that FLAG[1] = UP AND AFTER_YOU = 0 (quindi p1 ha invocato il lock e p0 dovrà aspettare).

• If p1 never locks anymore then p0 will eventually read F[1] and win (waiting 1).

• It is possible tho that p1 locks again:

  • if p0 reads F[1] before p1 locks, then p0 wins (waiting 1)
  • otherwise p1 sets A_Y to 1 and suspends in its wait (F[0] = up AND A_Y = 1), p0 will eventually rea