T 106.4155 Operating Systems: Concurrency Itlilja/os/lecture-3.pdf · Mutual Exclusion and...

T�106.4155 Operating Systems:Concurrency I

Timo Lilja

September 19, 20121

1$Id: lecture-3.tex 238 2012-09-14 10:12:07Z tlilja $Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 1 / 67

Mutual Exclusion and Synchronization

1 Mutual Exclusion and SynchronizationPrinciples of ConcurrencyMutual ExclusionSemaphoresMonitorsMessage PassingReaders/Writers Problem

Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 2 / 67

Mutual Exclusion and Synchronization Principles of Concurrency




Principles of Concurrency

In uniprocessor systems processes may be interleaved

In multiprocessor systems processes can be interleaved or overlapped

Di�culties of concurrency

sharing global resourcesoptimally allocating system resources�nding programming errors is di�cult since the results arenondeterministic and irreproducible



An Example

Consider a simple example

void echo()

chin = getchar();

chout = chin;

putchar(chout);

Interleaved execution on a multiprocessor system, the same line takesplace in parallel

P1: P2:

chin = getchar();

chin = getchar();

chout = chin; chout = chin;

putchar(chout);

putchar(chout);

The character input on P1 is lost and P2's input is displayed by bothprocesses



Enforcing single access

if we allow only one process to enter the echo process, we avoid thenondeterministic behavior

P1 and P2 run on separate processes

P1 enters echo �rst

P2 tries to enter but it is blocked

P1 completes execution

P2 resumes and executes echo



Race Condition

Race condition occurs when multiple processes read or write dataitems so that the �nal result depends on the order of execution of theprocesses

An example

Consider two processes P1 and P2 that share a global variable aP1 updates a to the value 1P2 updates a to the value 2Tasks P1 and P2 are in race with write variable athe �loser� of the race (here P2) determines the �nal value



Competition among Processes for Resources

Two processes are in con�ict when they compete for the same resource

Other process may slow down if it has to wait for the resource

Critical resource is the resource that is used by competing processes,the code that uses the resource is critical section

Control problems

deadlockstarvation

Mutual exclusion

no two processes can enter the critical section at the same time



Deadlock

Given two process P1 and P2 and two resources R1 and R2

Both resources are needed by the processes in order to proceed

OS assigns R1 to P1 and R2 to P2

Both processes are waiting for the other resources and cannot proceed



Starvation

Three processes P1, P2 and P3 require periodic access to R

P1 is in possession of the resource R

P1 is completed and OS schedules P3 to be executed next

After P3 OS schedules P1 again

P2 is starving, since it doesn't get executed at all


Mutual Exclusion and Synchronization Mutual Exclusion




Mutual Exclusion (1/2)

Requirements

must be enforced: only one process allowed to enter the critical section

a process that halts in non-critical section must do so withoutinterfering with other processes

process must not be delayed inde�nitely when requiring access tocritical section (no starvation or deadlock)

when no process is in CS, any process must be permitted to enterwithout delay

no assumptions about relative process speeds or number of processors

process must remain in CS for a �nite time only




there are n processes to be executed concurrentlyeach process operate on some resource Rato enforce mutual exclusion functions entercritical andexitcritical are providedthe functions take the resource to be controlled as an argument

PROCESS 1 */ void P1 { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }

/* PROCESS 2 */ void P2 { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }

• • •

/* PROCESS n */ void Pn { while (true) { /* preceding code */; entercritical (Ra); /* critical section */; exitcritical (Ra); /* following code */; } }

Figure 5.1 Illustration of Mutual Exclusion



Mutual Exclusion: Uniprocessor System Solution

In uniprocessor system, executions cannot overlap

Only interleaving is possible

A process continues to run until an interrupt or system call is invoked

Thus, to guarantee mutual exclusion, it is enough to disable interrupts



Mutual Exclusion: Multiprocessor System Solution

In multiprocessor system, the execution is concurrent

Processors share access to common main memory

There is no interrupt mechanism between processors

Access to a single memory location is atomic

if two processes try to access same memory location, one of them isblocked

Mutex is achieved by revising machine instructions that perform twooperations atomically

reading and writing a memory addressreading and testing a memory address



Mutual Exclusion: Hardware Support

compare and swapint compare_and_swap(int *word, int testval, int newval){

int oldval;oldval = *word;if (oldval == testval) *word = newval;return oldval;

}

exchangeint exchange (int register, int memory){

int temptemp = memory;memory = register;register = temp;

}

Even that code is C, it is executed atomically in a single instruction ona real CPU (e.g. x86 has XCHG instruction)



Mutual Exclusion: Protocol

/* program mutualexclusion */ const int n = /* number of processes */; int bolt; void P(int i) { while (true) { while (compare_and_swap(bolt, 0, 1) == 1) /* do nothing */; /* critical section */; bolt = 0; /* remainder */; } } void main() { bolt = 0; parbegin (P(1), P(2), . . . ,P(n)); }

/* program mutualexclusion */ int const n = /* number of processes**/; int bolt; void P(int i) { int keyi = 1; while (true) { do exchange (keyi, bolt) while (keyi != 0); /* critical section */; bolt = 0; /* remainder */; } } void main() { bolt = 0; parbegin (P(1), P(2), . . ., P(n)); }

(a) Compare and swap instruction (b) Exchange instruction

Figure 5.2 Hardware Support for Mutual Exclusion



Mutual Exclusion: Summary

Pros

applicable to any number of processorssimple and easy to verifycan support multiple critical sections

Cons

uses busy waiting which consumes CPU timestarvation is possible: no guarantees that all processes get their chanceto run once the resource is freedeadlock is possible

two processes P1 and P2 using same resource, P2 with higher priority

P1 executes compare-and-swap

P1 is interrupted and processor is given to higher priority P2 process

P2 ends up waiting for the resource in a busy loop

P1 won't get executed since P2 has higher priority

We need to devise some other mechanism to guarantee mutualexclusion at least for user level programs

but are there cases where spinlocks in userland are applicable?


Mutual Exclusion and Synchronization Semaphores




Semaphores (1/2)

An integer value used for signalling among processes

Three operations

initialize(S, n)

initialize semaphore S value to a given number nn indicates the number of processes allowed concurrently enter thesynchronized section

semWait(S)

decrement the semaphore value by 1if the value becomes negative ⇒ block

semSignal(S)

increment the semaphore value by 1wakeup a sleeping process if the pre-increment value was < 0



Semaphores (2/2)

Consequences

no way to know whether process decrementing a semaphore will blockafter incrementing a semaphore both incrementing and possibly wakenprocess continue to run

there is no way to know which will be run next

no way to know if another process is waiting

number ow woken processes may be zero or one



Semaphore Variants

Binary semaphore

can only have values 0 or 1semaphore can be locked by one process and released by another whilea mutex cannot ⇒ not the same as mutexeasier to implement but same expressive power than general semaphore

General or counting semaphore

can be initialized to any non-negative value

Strong Semaphore

order of removal is speci�ede.g. processes blocked in the wait queue for the semaphore areremoved in �rst-in-�rst-out (FIFO) order

Weak semaphore

order of removal is not speci�ed



Binary Semaphore De�nition

struct binary_semaphore { enum {zero, one} value; queueType queue; }; void semWaitB(binary_semaphore s) { if (s.value == one) s.value = zero; else { /* place this process in s.queue */; /* block this process */; } } void semSignalB(semaphore s) { if (s.queue is empty()) s.value = one; else { /* remove a process P from s.queue */; /* place process P on ready list */; } }

Figure 5.4 A Definition of Binary Semaphore Primitives



General Semaphore De�nition

struct semaphore { int count; queueType queue; }; void semWait(semaphore s) { s.count--; if (s.count < 0) { /* place this process in s.queue */; /* block this process */; } } void semSignal(semaphore s) { s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } }

Figure 5.3 A Definition of Semaphore Primitives



Example of Semaphore Mechanism (1/3)

Assume four processes A, B, C and D and a single semaphore s

Processes A, B, C depend on the result of D

1 A is running, s = 1, indicating that one of the results of D is available,A issues semWait (s = 0), A can continue

2 B issues semWait (s = -1), B is blocked

3 D issues semSignal (s = 0), B moves to ready queue

4 D moves to ready queue, C begins to run

5 C issues semWait (s = -1) and gets blocked, similarlyrunning A (s = -2) and B (s = -3) gets them blocked

6 D issues semSignal (s = -2) and transfers C to ready queue



Implementation of Semaphores (1/2)

semWait and semSignal must be implemented as atomic primitives

Hardware ⇒ usually not available

Pure software (like Dekker's algorithm) ⇒ overhead

must have sequential access to memorysee the Appendix A in the book

Hardware-supported schemes: compare & swap or test & set

Uniprocessor: disable interrupts



Implementation of Semaphores (2/2)

semWait(s) { while (compare_and_swap(s.flag, 0 , 1) == 1) /* do nothing */; s.count--; if (s.count < 0) { /* place this process in s.queue*/; /* block this process (must also set s.flag to 0) */; } s.flag = 0; } semSignal(s) { while (compare_and_swap(s.flag, 0 , 1) == 1) /* do nothing */; s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } s.flag = 0; }

semWait(s) { inhibit interrupts; s.count--; if (s.count < 0) { /* place this process in s.queue */; /* block this process and allow interrupts */; } else allow interrupts; } semSignal(s) { inhibit interrupts; s.count++; if (s.count <= 0) { /* remove a process P from s.queue */; /* place process P on ready list */; } allow interrupts; }

(a) Compare and Swap Instruction (b) Interrupts

Figure 5.14 Two Possible Implementations of Semaphores



Mutual Exclusion using Semaphores (1/3)

Assume N processes that need access to the same resource in CS

Semaphore s initialized to 1

semWait(s) is executed before entering the critical section

if s = 1 the value s is decremented and process enters CSbecause s ≤ 0, no other process can enter CS

Any number of processes may try to enter CS but will block anddecrement the value of the semaphore s

Once the process in the CS departs, it increments s

one of the blocked processes (if any) is removed from the ready queue




What happens if we initialize s to some other positive value than 1?




The value of s.count can be interpreted

s.count ≥ 0: number of processes that execute semWait(s) withoutsuspension

allows semaphores support both synchronization and mutual exclusion

s.count < 0: number of processes suspended on s.queue. I.e., numberof processes waiting access for the critical section



The Producer/Consumer Problem

A shared bu�er in the memory

One or more producers generating data and adding it the bu�er

Single consumer taking data from the bu�er

Synchronization problem

only one process can access the bu�er at a timeconsumer won't remove data from an empty bu�er

Variations for both in�nite and �nite bu�er

in �nite bu�er, producer can't write if the bu�er is full

producer: consumer:while (true) { while (true) {

/* produce item v */ while (in <= out)b[in] = v; /* do nothing */in++; w = b[out];

} out++;/* consume item w */

}



In�nite P/C Solution Using General Semaphores (1/2)

Semaphore(s) protecting access to functions updating bu�ersappend() and take(), initialized to 1 indicating that one ofproducer/consumers should be able to enter CS

Semaphore(n) allowing producer to signal consumer when the bu�erhas data available for reading, initialized to 0 indicating that no datais initially available in the bu�er



In�nite P/C Solution Using General Semaphores (2/2)

/* program producerconsumer */ semaphore n = 0, s = 1; void producer() { while (true) { produce(); semWait(s); append(); semSignal(s); semSignal(n); } } void consumer() { while (true) { semWait(n); semWait(s); take(); semSignal(s); consume(); } } void main() { parbegin (producer, consumer); }

Figure 5.11 A Solution to the Infinite-Buffer Producer/Consumer Problem

Using Semaphores


Mutual Exclusion and Synchronization Monitors




Monitors

With semaphores it is di�cult to write a correct program becausesemaphore operations are scattered throughout the program

A monitor is a synchronization construct that provides equivalentfunctionality

monitors consist of one ore more procedures,initialization sequence and local datalocal data is accessible only by the monitor's proceduresa process enters the monitor by invoking one of its processesonly one process may be executing the monitor at a time

Monitors support synchronization primitive called condition variables

cwait(c) suspend the execution of the process on condition c.The monitor can be used by other processescsignal(c) resume the execution of the blocked process after a cwait(c).If there are several processes choose one, if there are none, do nothing



Structure of a Monitor

Entrance

queue ofentering

processes

Exit

condition c1

cwait(c1)

urgent queue

csignal

condition cn

cwait(cn)

local data

condition variables

Procedure 1

Procedure k

initialization code

Figure 5.15 Structure of a Monitor

monitor waiting area

MONITOR



Bounded-bu�er P/C Using a Monitor (1/3)

Two condition variables

notfull: room to add at least one characternotempty: there is at least one character

Method append

append characters if notfull, otherwise blocksignal notempty to inform that there is a character

Method take

take characters if notemptysignal notfull once process has taken a character



Semaphores vs. Monitors (1/2)

With semaphores, the synchronization is scattered throughoutthe program

With monitors, the synchronization needs to be done only in monitor

which is precisely the part that handles the shared data structure



Semaphores vs. Monitors (2/2)

vs

/* program boundedbuffer */ const int sizeofbuffer = /* buffer size */; semaphore s = 1, n= 0, e= sizeofbuffer; void producer() { while (true) { produce(); semWait(e); semWait(s); append(); semSignal(s); semSignal(n); } } void consumer() { while (true) { semWait(n); semWait(s); take(); semSignal(s); semSignal(e); consume(); } } void main() { parbegin (producer, consumer); }

Figure 5.13 A Solution to the Bounded-Buffer Producer/Consumer

Problem Using Semaphores



Hoare vs. Lampson�Redell Monitors (1/3)

Hoare's (the previous) de�nition requires that if there's a process in thequeue for condition c , it runs immediately when another process issuescsignal(c)

if the process issuing csignal is not �nished with the monitor, need twocontext switches to resume computation

process scheduling must be perfectly reliable: no other process mayenter the monitor before the signaled process gets executed otherwisethe signal condition may not hold

if a producer process appends a new character to the bu�er and failsbefore signaling notempty ⇒ all processes waiting for the condition arepermanently hung




Lampson�Redell Monitors (MESA) de�nition

replace csignal with cnotify(q): the queue q will be noti�ed but thecurrent process continues to execute

a process in the queue q will be executed at some later time

there is no guarantee that other processes won't enter the monitorbefore the process in the head of queue q

the process must check that the condition is still valid(replace if's with while loops)




Hoare

Mesa



Lampson�Redell Monitor Advantages

Signaled process checks the condition and goes back to sleep if thecondition is not met

an incorrect signaling or broadcast does not cause erroneous behavioras it would with Hoare's monitors

Consider implementing a bu�er allocator with two levels of conditionsneeded to be satis�ed by co-operating processes

1 mutex access to the shared data structures2 enough memory for this process to complete the request

Hoare: signal implies (1) and implicitly (2)In L-R: the waiting process must check invariant (2)Thus, if programmer changes the invariant (2), heneeds to reprogram all signaling when using Hoare's monitors

Thus, Lampson�Redell monitors enforce more modular andless error prone design

but in practice libraries implement both! Why?


Mutual Exclusion and Synchronization Message Passing




Message Passing

Processes interacting between each other need to synchronize andcommunicate

In message passing a process sends a message to another processdesignated by a destination by invoking the primitive

send(destination, message)

Another process receives the message by calling

receive(source, message)

Message passing is applicable both in shared memory computers andnon-shared memory (distributed) systems

you can use message passing in shared memory systems too

A note on terminology:

programs can have concurrency in them (e.g. algorithms)parallel execution is the property of the machinein distributed computing, systems are autonomous and usually don'tshare common memory



Synchronization

When a message has been sent the sent via send() the process canblock until the message is received or continue execution

Similarly, when a process issues receive()

the call can return immediately if there is a message waitingit can block if there are no messages waitingcan return immediately and abandon receiving the message

Combinations

blocking send/blocking receive: called rendezvous,provides tight synchronization between processesnon-blocking send/blocking receive: usual case, since a process cansend a message and do useful work but the receiving (server) processcan't do anything until a request arrivesnon-blocking send/non-blocking receive: synchronization is not verytight, applicable when both processes can do useful work without themessages



Addressing (1/2)

Direct addressing

send primitive explicitly speci�es destinationreceive can either designate sending process or accept all connectionsand implicitly pass the senders address when returning

Indirect addressing

message not send directly between sender and receivermailbox: a queue holding the message until it is delivered

Indirect addressing allows more �exible messaging

one-to-onemany-to-oneone-to-manymany-to-many



Addressing (2/2)

S1

Sn

R1

Rm

Mailbox

S1

Sn

R1Port

Figure 5.18 Indirect Process Communication

(b) Many to one

S1 R1Mailbox

S1

(a) One to one

(d) Many to many

R1

Rm

Mailbox

(c) One to many



Message Formats

Objectives: single computer or distributed system?

Fixed or variable length size?

Pass-by-Reference or pass-by-value?

if a large amount of data to be transfered, send a link instead

Contents

header (type, destination addr, source addr, length, control info)body: data




Messages can be used to enforce mutual exclusion

Assuming blocking receive and non-blocking send

A set of processes share a mailbox mbox

initialized to contain null message

A process entering the CS issues receive

if the box is empty, receive blocksotherwise, it empties the box and enters critical section

Once process is �nished with CS, it puts the message back to mbox

If more than one process performs receive concurrently

message is delivered to only one process and others blockall processes are blocked if the queue is emptyone process is activated when a message arrives




/* program mutualexclusion */ const int n = /* number of processes */; void P(int i) { message msg; while (true) { receive (box, msg); /* critical section */; send (box, msg); /* remainder */; } } void main() { create_mailbox (box); send (box, null); parbegin (P(1), P(2), . . ., P(n)); }

Figure 5.20 Mutual Exclusion Using Messages



Bounded-Bu�er Producer/Consumer (1/2)

mayconsume message

sent by the producer once the data has been generatedif there is at least one message, consumer can consumeserver as the bu�erdata organized as a queue of messages

Variable capacity determines the bu�er size

mayproduce message

initialized with number of null message indicated by variable capacitynumber of messages shrinks/increases when consumed/produced

Flexible

scales to any number of producers and consumerscan be located on di�erent machines (distributed)



Bounded-Bu�er Producer/Consumer (2/2)

const int capacity = /* buffering capacity */ ; null = /* empty message */ ; int i; void producer() { message pmsg; while (true) { receive (mayproduce, pmsg); pmsg = produce(); send (mayconsume, pmsg); } } void consumer() { message cmsg; while (true) { receive (mayconsume, cmsg); consume (cmsg); send (mayproduce, null); } } void main() { create_mailbox (mayproduce); create_mailbox (mayconsume); for (int i = 1; i <= capacity; i++) send (mayproduce, null); parbegin (producer, consumer); }

Figure 5.21 A Solution to the Bounded-Buffer Producer/Consumer Problem

Using Messages Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 57 / 67

Mutual Exclusion and Synchronization Readers/Writers Problem




Readers/Writers Problem

In readers/writers problem

there are a number of processes sharing a data area

there are a number of processes only reading the data

there are a number of processes only writing the data1 any number of readers can simultaneously read the data2 only one writer may write the data3 if a writer is writing the �le, no reader can read it

not the same as producer/consumer (P/C)

P is not just a writer: reads queue pointers to write next itemC is not just a reader: writes queue pointers to show it has used an item

not the same as mutual exclusion

if process do R/W access, we must use mutexR/W allows more e�cient solutions due to the fact we understandbetter how the processes share the dataConsider a library catalog: N users can read and one librarian update.Mutex would lock the system whenever there is an access to the catalog



Readers Have Priority (1/2)

The wsem enforces mutual exclusion between R and W

if there is one W, no other R/W can access the data

To allow multiple readers

if there is no other readers, we must wait wsemsince a writer might be activeif there are more readers, no need to wait becausewe already know that reading is OKvariable readcount: track the number of readerssemaphore x: protects access to the variable readcount



Readers Have Priority (2/2)

/* program readersandwriters */ int readcount; semaphore x = 1, wsem = 1; void reader() { while (true) { semWait (x); readcount++; if (readcount == 1) semWait (wsem); semSignal (x); READUNIT(); semWait (x); readcount--; if (readcount == 0) semSignal (wsem); semSignal (x); } } void writer() { while (true) { semWait (wsem); WRITEUNIT(); semSignal (wsem); } } void main() { readcount = 0; parbegin (reader, writer); }

Figure 5.22 A Solution to the Readers/Writers Problem Using

Semaphores: Readers Have Priority



Writers Have Priority (1/3)

Once a reader is reading, readers can retain the control inde�nitely

writers are subject to starvation

We want to guarantee that readers can't access data when there is atleast one writer wanting to write

Add the following semaphores and variables

Semaphore rsem: inhibits reads when there is at least one writer readyvariable writecount: control the setting of rsemsemaphore y: protects the variable writecount

Queue must not be allowed to build up on rsem

otherwise writers would not be able to jump the queuethus, only one reader is allowed to queue on rsemrest of the readers queue on semaphore z before queuing rsem



Writers Have Priority (2/3)

Table 5.6 State of the Process Queues for Program of Figure 5.23

Readers only in the system

•wsem set

•no queues

Writers only in the system

•wsem and rsem set

•writers queue on wsem

Both readers and writers with read first

•wsem set by reader

•rsem set by writer

•all writers queue on wsem

•one reader queues on rsem

•other readers queue on z

Both readers and writers with write first

•wsem set by writer

•rsem set by writer

•writers queue on wsem

•one reader queues on rsem

•other readers queue on z



Writers Have Priority (3/3)/* program readersandwriters */ int readcount, writecount; semaphore x = 1, y = 1, z = 1, wsem = 1, rsem = 1; void reader() { while (true) { semWait (z); semWait (rsem); semWait (x); readcount++; if (readcount == 1) semWait (wsem); semSignal (x); semSignal (rsem); semSignal (z); READUNIT(); semWait (x); readcount--; if (readcount == 0) semSignal (wsem); semSignal (x); } } void writer () { while (true) { semWait (y); writecount++; if (writecount == 1) semWait (rsem); semSignal (y); semWait (wsem); WRITEUNIT(); semSignal (wsem); semWait (y); writecount--; if (writecount == 0) semSignal (rsem); semSignal (y); } } void main() { readcount = writecount = 0; parbegin (reader, writer); }

Figure 5. 23 A Solution to the Readers/Writers Problem Using

Semaphores: Writers Have Priority Timo Lilja () T�106.4155 Operating Systems: Concurrency ISeptember 19, 20121 64 / 67


R/W in Message Passing (1/2)

Message Passing solution involves a control process that has access tothe shared data area

Readers and Writers send request messages to the controller to getaccess to the data area

controller grants access with �OK� message is receivedreader/writers indicate the completion with ��nished� message

Controller has mail boxes for each type msgthe controller serves write requests before read requests by emptyingthe write mailbox �rst

To guarantee mutual exclusion, variable count is usedinitialized to greater than the maximum number of readerscount > 0: no writer is waiting, service all ��nished� to clear activereaders, service write requests and then read requestscount = 0: only one outstanding write request, allow the write toproceed and wait for a ��nished� messagecount < 0: writer has made a request and is waiting for outstandingreaders, serve only ��nished� messages



R/W in Message Passing (2/2)

void reader(int i) { message rmsg; while (true) { rmsg = i; send (readrequest, rmsg); receive (mbox[i], rmsg); READUNIT (); rmsg = i; send (finished, rmsg); } } void writer(int j) { message rmsg; while(true) { rmsg = j; send (writerequest, rmsg); receive (mbox[j], rmsg); WRITEUNIT (); rmsg = j; send (finished, rmsg); } }

void controller() { while (true) { if (count > 0) { if (!empty (finished)) { receive (finished, msg); count++; } else if (!empty (writerequest)) { receive (writerequest, msg); writer_id = msg.id; count = count – 100; } else if (!empty (readrequest)) { receive (readrequest, msg); count--; send (msg.id, "OK"); } } if (count == 0) { send (writer_id, "OK"); receive (finished, msg); count = 100; } while (count < 0) { receive (finished, msg); count++; } } }

Figure 5.24 A Solution to the Readers/Writers Problem Using Message Passing



Shared vs. Share-Nothing Concurrency

In shared concurrency processes/threads see others memory

one process can write others memory and cause bugs that manifest alot later ⇒ hard to debug

allows very e�cient communication and synchronization

In share-nothing concurrency processes must communicate via messages

single entry/exit point for the data ⇒ easer to separate and verify thecorrectness of communication

synchronization is still an issue

you can have deadlocks, starvation and such

can be ine�cient when compared to shared memory

but you can have both: message passing on top of shared memory


T 106.4155 Operating Systems: Concurrency Itlilja/os/lecture-3.pdf · Mutual Exclusion and...

Documents

Transcript of T 106.4155 Operating Systems: Concurrency Itlilja/os/lecture-3.pdf · Mutual Exclusion and...