Tasks and Intertask CommunicationIntroduction

Multitasking / Multithreading systemSupports multiple tasks

As we’ve notedImportant job in multitasking system

Exchanging data between tasksSynchronizing tasksSharing resources

Let’s now examine these issues

Interprocess / Interthread CommunicationWhen threads operating independently

Our systems have few if anyConflictsChances for corruptionContentions

Real systemsThe interesting onesMust deal with all such problems

Resources and inter thread communicationMust take place in robust manner

Interaction may be Direct or indirectMust be synchronized and co-ordinated

Want to prevent race conditionsOutcome of task or computation

Depends upon order in which tasks executeLet’s begin by looking at shared information

Can occur in a variety of ways

- 1 of 25 -

Shared VariablesSimplest solution is shared memory environment

Global VariablesSimplest and fastest of these is

Global variablesObvious problems

Higher priority process can pre-emptModify global data

Shared BufferScheme says two processes share common set of

Memory locationsProducer

Puts data into bufferConsumer

RemovesSeveral obvious problems

Arise if one process faster than otherBuffer size critical to avoid such problems

Shared Double BufferScheme says two processes share two common sets of

Memory locationsCalled ping-pong buffering scheme

Effective between processes running at different ratesOne buffer being filled while other being emptied

Consumer blocks on lack of dataProducer must still avoid over running buffer

Ring BufferScheme FIFO structure studied earlierPermits simultaneous input and output

Using head and tail pointersMust be careful to manage

OverflowUnderflow

- 2 of 25 -

MailboxMutually agreed upon memory location

Two or more tasks use to pass dataTasks rely on main scheduler to permit access

Post operation for writePend operation for read

Pend operation different from pollPoll task continually interrogates variablePend task suspended while data not available

Variety of things passedSingle bit

FlagSingle data wordPointer to data buffer

In most implementationsPend operation empties mailbox

If several tasks pending on flagEnabled task resets flagBlocks multiple accesses to resource

On single flagSome implementations

Permit queue of pending elementsRather than single entry

Such scheme may be usefulMultiple independent copies of critical resource

MessagesMessage exchange is another means for communicationNow starting to move more into distributed systems

Called interprocess communication facility (IPC)Note IPC is not mutually exclusive with shared memoryIdea to permit processes to communicate

Without resorting to shared variablesParticularly in different address spaces

- 3 of 25 -

IPC provides two operationsSendReceive

Messages may be fixed or variable sizeBasic Structure

If processes P1 and P2 wish to communicateMust

Send and receive messagesEstablish a communication link

QuestionsVariety of questions one may ask

How to establish linkCan link be associated with multiple processesHow many links between pair or processWhat is link capacity and are there buffersWhat is message sizeAre links

UnidirectionalBi-directional

Implementation methodsDirect / Indirect communicationSymmetric / asymmetric communicationAuto or explicit bufferingSend by copy or referenceFixed or variable sized messages

Let’s look at several of theseCommunication

DirectEach process must explicitly name sender / receiver of messageMessages logically of form

send (P1, message) // send message to P1receive (P2, message) // receive message from P2

- 4 of 25 -

Link propertiesLink automatically established between every pair of processesProcesses need ony know each others identityLink associated with only two processesBetween each pair

Only single linkLink may be

Uni/bi directional

ExampleConsider skeletal structure

Between producer P1 and consumer P2

Observe scheme uses Symmetrical addressing

Sender and receiver must name each otherIf want asymmetric; addressing

Sender only names recipientDisadvantage

Ties process name to implementation

IndirectMessages sent / received from shared variable

Generally in form of mailbox

send (M0, message) // send message to mailbox M0receive (M0, message) // receive message from mailbox M0

repeat...produce item in nextP1

...send (P2, nextP1)

until forever

repeat...receive(P1, nextP2)

...consume item in nextP2

until forever

- 5 of 25 -

PropertiesLink established

Only if processes have shared mailboxLink may be associated with multiple processesMay be multiple links between processesLink may be uni/bi directional

Consider 3 processes P0, P1, P2All share M0Let P0 send and P1 and P2 receive

Question - who gets messageSolution

Associate link with at most 2 processesAllow only one process to receive at a timeLet system select receiver

Mailbox ownerProcess

If process owns mailboxCan distinguish between

Owner Who can only receive

UserWho can only send

Since each mailbox has unique ownerNo ambiguity

SystemExists independent of any processOS provides mechanism for process to

Create new mailboxSend / receive messages through mailboxDestroy mailbox

Creating processMay pass access privlegesShare mailbox

Must manage memory associated with mailboxsFor which no process has access rights

- 6 of 25 -

BufferingEstablishes number of messages

Temporarily reside in linkThree possibilities

Zero capacityLink cannot store messageSender must wait for receiver to accept messageCalled rendez vous

Bounded capacityMessage queue has length nIf space remaining

Sender can place message in queueContinue

ElseSender must wait for space

UnboundedPotentially infinite lengthSender can post message

ContinueNo wait

- 7 of 25 -

Indirect

Buffer

Must Establish Protocol Link

Owned by Process System

mailbox

Direct

P2P1Global VariableShared Buffer

Ping PongRing or FIFOMail Box

SharedVariable

Message

- 8 of 25 -

Thread SynchronizationCo-operating threads

One that can affect or be affected by another threadsMay directly share logical address space

Code and dataBe allowed to share data only

Through filesConcurrent access to shared data

Can result in data inconsistency

Critical SectionsConsider following problem and code fragments

Exchanging messages through bounded bufferAllow n items in bufferAlgorithm says

Producer If not full

add item increment count

else wait until space

ConsumerIf item

get itemdecrement count

elsewait until item

Producer repeat

...

produce an item in nextP1

while (count == n); // buffer full

buffer[in] = nextP1;

in = (in + 1) % n;

Consumerrepeat

while (count ==0); // buffer empty

nextP2 = buffer[out];out = (out+1) % n;count--;...consume nextP2;...

until forever

- 9 of 25 -

ProblemValue of count

Depends upon who accesses variableMay be any of 3 different values

Variable count is critical variableWithin P1 or P2

Denoted critical sectionCritical section in general

Section of code in which process is changing common variablesFileTableetc

While process in critical sectionWant to prevent access by all other processes

Termed mutual exclusionAbstractly may represent code as

SemaphoresSolution to critical section problem must satisfy following requirements

mutual exclusionIf process P1 is in critical section

No other process may enterprogress

If no process in critical section and some process wish to enterOnly processes not in remainder section

Can participate in decisionDecision cannot be postponed indefinitely

repeat entry section

critical section

exit section

remainder section

until forever

- 10 of 25 -

bounded waitingMust be bound on number of times other processes can enter critical section

After a process has made a request to enterBefore request granted

Methodology to protect critical section suggested by DijkstraCalled semaphoreSemaphore

Integer or Boolean variable - SAccessed only through two atomic operations

wait - P(S)signal - V(S)

Operations may be defined by following code fragments

s is initialized to FALSE

These may now be used as

wait(s) {

while (s);s = TRUE;

}

signal(s) {

s = FALSE;}

Process 1{

…wait(s)

critical sectionsignal(s)…

}

Process 2{

…wait(s)

critical sectionsignal(s)…

}

- 11 of 25 -

Consider two concurrently running processes p1 and p2 letp1

Contain statement s1 p2

Contain statement s2

We require s1 be executed before s2Thus define semaphore sync

Initialize sync to TRUE

ObserveBecause synch initialized to TRUE

p2 will execute s2 only afterp1 executes s1

Spin LockMain disadvantage of semaphores as described

When wait encounteredEncountering process blocked

Must loop continuously while waitingCalled busy waitingWaiting processes waste CPU cycles while waiting

Other process could use productivelySuch a semaphore called spinlock

Because process spins while waiting for lockAdvantage of spinlock

No context switchCan take long time

If lock expected to be held for short timeSpinlock useful

p1 ...

s1signal(sync) // signal...

P2 ...

wait(sync) // waits2...

- 12 of 25 -

To overcome need for busy waitingModify definition of semaphore operations

When process executes wait operationIf semaphore TRUE

Must waitRather than wait process can block itself

Block operation places self in waiting queueAssociated with semaphore

Process state changed to waitingControl transferred to scheduler

Blocked process should be restartedSome other process executes signal operationProcess

Restarted By wakeup operationPlaces process in ready state

Placed in ready queueSemaphore now defined as follows

s initialized to 1

Note semaphore now has integer valueblock operation suspends invoking processwakeup resumes execution of blocked processBoth operations provided by operating system calls

ObserveWaiting list can be implemented by linked list

Perhaps implement as FIFO queue

wait(s){

s = s-1; // on first pass s == 0if (s < 0){

add process to waiting queue;block;

}}

signal(s) {

s = s+1;if (s <=0){

remove process from waiting queue;wakeup(p);

}}

- 13 of 25 -

Mutexes and Counting SemaphoresSemaphores we’ve looked at called binary semaphores

Can take on either one of two valuesMutex

Binary Used to serialize access to reentrant codeAllows only one thread into controlled code sectionExample

Key to toiletSemaphore

Counting Can take on more than two values

Like previous example Used to protect pools of resources or track number or resourcesRestricts number of simultaneous users (threads) of shared resourceExample

Number of keys to toilet

Working with a counting semaphore - let’s call these wait - wait(s)signal - sig(s)

Each semaphore hasInteger valueList of associated processes

When process must wait on semaphoreAdded to list of processes

wait(s){

s--;if (s<0)add this process to queue;block;

}

sig(s){

s++;if (s<=0)remove a process Pi from queue;wakeUp(Pi);

}

- 14 of 25 -

SignalRemoves process from list Awakens it

Operations may be defined by following code fragments

Bounded Buffer ProblemLet’s look at one classic synchronization problemConsider we have a pool of n buffers

Each can hold one item in this exampleWe define semaphores

mutexProvides mutual exclusion for accesses to buffer poolInitialized to value 1

Empty - semaphoreCount number of empty buffersInitialized to n

Full - semaphoreCount number of full buffersInitialized to 0

Code fragments illustrated as

Producerrepeat

...produce an item anItem...wait(empty); // check for non zero

// dec empty cntwait(mutex);...

add anItem to buffer nextProd;...signal(mutex);signal(full); // inc full cnt...

until false

Consumerrepeat

wait(full); // check for non zero // dec full cnt

wait(mutex);...

remove anItem from buffer nextCons;...signal(mutex);signal(empty); // inc empty cnt... consume item anItem...

until false

- 15 of 25 -

Readers and Writers ProblemData object may be shared among several concurrent processesSome may want to read and others may want to writeProcesses referred to as

ReadersWriters

If 2 readers access simultaneouslyNo problem

If writer and any other process access simultaneouslyBig problem

Referred to as readers - writers problemSeveral variations

First readers-writersNo reader waits

Unless writer has obtained access of shared variableSecond readers-writers

Once writer ready Performs write as soon as possible

If writer waitingNo new reader started

Solution to first readers-writers problemDefine

Semaphores - mutex, wrtSemInitialize to 1mutex - ensure mutual exclusion when readcount updatedwrtSem - mutual exclusion for writers

integer - numReadersInitialize to 0numReaders - count of readers currently accessing shared variable

Code fragment given as:

Writer Processwait(wrtSem); // wait for wrtSem == 1

// wrtSem = 0...perform writing;...

signal(wrtSem); // wrtSem = 1...

Reader Processwait(mutex); // wait while mutex == 1

// mutex = 0numReaders++; // inc number of readersif (numReaders ==1) // if i’m the only reader

wait(wrtSem); // make sure no writers // wrtSem = 1

signal(mutex); // mutex = 0...

Perform reading;...

wait(mutex); // wait for mutex == 1

- 16 of 25 -

NoteIf writer in critical section and n readers waiting

One reader queued on wrtSemn-1 readers queued on mutex

If writer executes signal(wrtSem)May resume

Waiting readersOne waiting writer

Decision made by scheduler

MonitorsSemaphores we’ve studied

Fundamental synchronism mechanismHowever low-level mechanism

Easy to make errors with them

Reader Processwait(mutex); // wait while mutex == 1

// mutex = 0numReaders++; // inc number of readersif (numReaders ==1) // if i’m the only reader

wait(wrtSem); // make sure no writers // wrtSem = 1

signal(mutex); // mutex = 0...

Perform reading;...

wait(mutex); // wait for mutex == 1

- 17 of 25 -

Monitors are program modulesOffer more structure than semaphores

Implementation can be as efficientMonitors

Data abstraction mechanismEncapsulate

Representation of abstract objectProvide public interface

Only means by whichInternal data may be manipulated

Contains variable toStore object’s stateProcedures that implement operations on object

We satisfy mutual exclusion By ensuring

Procedures in same monitorCannot execute simultaneously

Conditional synchronizationProvided through condition variables

Monitor used to groupRepresentation and implementation

The interface and bodyOf shared resource

Has interface and bodyInterface

Specifies operations and behaviour provided by resourceBody

Contains Variables

Represent state of resourceProcedures

Procedures Implement operations specified in interface

- 18 of 25 -

Schematically we have

Procedures implementVisible operations

Permanent variablesShared by all processes

In the monitorLike statics in C++ or pool variables in Smalltalk

Denoted permanentRetain values on exit

As long as monitor existsProcedures

May have local variables

By virtue of being an Abstract Data TypeMonitor is a distinct scope

Only procedure names – this is the public interfaceVisible outside of monitor

Permanent variablesCan only be changed

Through one of the visible proceduresStatements within monitor

Cannot affect variables outside monitorIn different scope

Permanent variablesInitialized before any procedure calledAccomplished by

Executing initialization proceduresWhen monitor instance created

monitor monName{

initialization statements //analogous to constructorprocedurespermanent variables

}

- 19 of 25 -

Monitor sounds very similar to C++ classMajor difference

Monitor shared by multiple concurrently executing processes or threadsConsequently

Threads or processes using monitorMay require

Mutual exclusionTo monitor variables

SynchronizationTo ensure monitor state conducive to continued execution

Mutual exclusionUsually implicit

SynchronizationImplemented explicitly

Different processes require different forms of synchronizationImplementation achieved through

Condition variablesShared variables discussed earlier

Monitor procedure Called by external process or threadA procedure is active

If a thread or process executing Statement in procedure

At most one instance of monitor procedureActive at any one time

Cannot haveTwo different procedures invoked

orTwo invocations of same procedure

By definitionExecute with mutual exclusion

Ensured byLanguageLibraryOperating system

- 20 of 25 -

Generally implemented Locks or semaphoresInhibiting certain interrupts

Condition VariablesCondition variables used as part of synchronization process

Used to delay thread or process that Cannot safely continue

Until monitor’s state satisfies some Boolean conditionUsed to awaken delayed process

Once condition becomes true

Condition variableInstance of variable of type cond

cond myCondVar;Can only be declared inside monitorValue of condition thus it represents a queue

Queue of delayed processesInitially queue is emptyValue can only be accessed indirectly

Much like private variables in C++ or JavaTest state

empty(myCondVar);Thread can block on a condition variable

wait(myCondVar);Execution of wait causes process to

Move to rear of queueRelinquish exclusive access to monitor

Blocked process awakenedsignal(myCondVar);Execution of signal causes thread

At head of queue to awaken

Execution of signalSeems to cause dilemma

Upon execution two processes have potential to executeAwakened threadSignaling thread

- 21 of 25 -

Contradicts requirementOnly single thread active in monitor at once

Two possible paths for resolution Signal and continue

Signaling thread continues Awakened process resumes at some delayed timeConsidered nonpreemptive

Process executing signalRetains exclusive control of the monitor

Signal and waitConsidered to be preemptiveProcess executing signal

Relinquishes control and passes lockTo awakened process

Awakened process preempts signaling processCan describe process with following state diagram

Operation / synchronization occurs as followsThread calls monitor procedureIf another thread executing in monitor

Caller placed into entry queueWhen monitor becomes free

Result of return or waitOne thread moves from entry queue into monitor

Else passes through entry queueBegins executing immediately

If thread executes wait on a condition variable

- 22 of 25 -

While executing in monitorThread enters queue associated with that variable

When thread executes Signal and Continue on a condition variable

Thread at head of associated queueMoves to entry queue

Signal and Wait on a condition variableThread at head of associated queue

Moves to monitorThread executing in monitor

Moves to entry queue

Bounded Buffer Problem with MonitorLet’s look at one classic synchronization problem

Looked at earlier with semaphoresImplemented with monitorConsider we have a pool of n buffers

Each can hold one item in this example

We define a monitor boundedBuffer

We define condition variables notEmpty

Signaled when buffer count > 0Tracks empty buffersinitialized to 0

notFullSignaled when buffer count < nTracks full buffersInitialized to 0

We define procedures put(data)

Puts data into a buffer When space available

- 23 of 25 -

get(data)Gets data from a buffer

When data availableWe define the protected entity

bufferPool

We can implement our monitor as follows

Code fragments illustrated as

Deadlocks and StarvationDeadlocksImplementation of semaphore or monitor with waiting queue

Producerrepeat

...produce an item anItem...boundBuffer.put(anItem)...

forever

Consumerrepeat

... boundBuffer.get(anItem)…consume item anItem...

forever

monitor boundBufferbufferPool;count = 0;cond notEmpty; // signaled when count > 0cond notFull; // signaled when count < n

put(anItem){

while(count == n) wait (notFull);put anItem into a buffersignal (notEmpty);

}get(anItem){

while(count == 0) wait (notEmpty);get anItem from a buffersignal (notFull);

}

- 24 of 25 -

Can result in situation in which 2 or more processesWait indefinitelyCalled deadlock

Consider 2 processes P0 and P1Let each process have 2 semaphores

S1 and S2May be resources each needs

R1 and R2Need both to continue

Let R1 and R2 be set to value 1

Let P0 set wait(S1) // wait for R1 decrement S1 (=0)P1 set wait(S2) // wait for R2 decrement S2 (=0)

Now let P0 set wait(S2) // wait for R2 decrement S2 (=-1)P1 set wait(S1) // wait for R1 decrement S1 (=-1)

At this pointP0 must wait for signal(S2)P1 must wait for signal(S1)These operations cannot be executed

Processes blockedEvery process in set waiting for event

Possible only by another member in setWill discuss in much greater detail shortly

- 25 of 25 -

Starvation Problem called starvation can occur

Process waiting within semaphoreOther processes added or removed

LIFO order

Events and SignalsSome languages provide mechanisms for handling

Asynchronous eventsProvides software interrupt

Generally used for exceptionsDivide by zeroArithmetic overflowetc.

In addition to built in proceduresSome permit user defined procedures to be

Provided and executedANSI-C

Provides signal and raiseSignal

Software interrupt handlerResponds to exceptions indicated by raise

RaiseMechanism to signal an exception or event

Both implemented as function callsPassing pointers to functions

Can handle variety of events or exceptions

- 26 of 25 -