Post on 14-Dec-2015
Concurrency
Characteristics of concurrent / interleaved processes:
• share/compete for resources
• communicate
• synchronize their activities
Concurrency
• Same problems in multiprogramming and multiprocessing
• Basic method to support concurrency– mutual exclusion: the ability to exclude all other
processes from a course of action while one process is engaged in that action
‘one processor’ case
The echo procedure and its variables are shared by two processes P1 and P2
P1: chin = getchar(); // user types ‘x’interrupted, chin contains ‘x’
P2: chin = getchar(); // user types ‘y’ chout = chin; putchar(chout); // ‘y’ is displayed
interrupted, chin contains ‘y’
P1: chout = chin; putchar(chout); // ‘y’ is displayed
instead of ‘x’
‘two-processors’ case
Process P1 Process P2
. .
in = getchar(); .
. in = getchar();
chout = chin; chout = chin;
putchar(chout); .
. putchar(chout);
. .
Operating System Concerns
• Keep track of active processes
• Allocate and deallocate resources– Processor time– Memory– Files– I/O devices
• Protect data and resources
• Result of process must be independent of the speed of execution of other concurrent processes
Process Interaction
• Processes unaware of each other– Independent– competition for resources
• Processes indirectly aware of each other– share access to some object– cooperation
– data coherence problem
• Process directly aware of each other– work jointly on some activity – communicate via messages to coordinate activities– cooperation
Control problems
• Mutual exclusion
• Two processes require access to a single non-shareable resource.
• Critical resource - the resource in question.
• Critical section in the program - the portion in the program that uses the resource
• The rule: only one program at a time be allowed in its critical section
Deadlock
• Deadlock
• Involves at least two processes
• P1 waits for an event to be produced by P2
• P2 waits for an event to be produced by P1
Starvation
• Starvation
• Involves at least three processes P1, P2, P3, competing for non-shareable resource
• P1 and P2 alternatively use the resource
• P3 may indefinitely be denied access to that resource.
Competition Among Processes for Resources
• Mutual Exclusion– Critical sections
• Only one program at a time is allowed in its critical section
• Example only one process at a time is allowed to send command to the printer
• Deadlock• Starvation
Cooperation Among Processes by Sharing
• Writing must be mutually exclusive
• Critical sections are used to provide data integrity
Cooperation Among Processes by Communication
• Messages
– Mutual exclusion is not a control requirement
• Possible to have deadlock
– Each process waiting for a message from the other process
• Possible to have starvation
– Two processes sending message to each other while another process waits for a message
Requirements for Mutual Exclusion
• Only one process at a time is allowed in the critical section for a resource
• A process that halts in its non-critical section must do so without interfering with other processes
• No deadlock or starvation• Grant access to a critical section when there is no
other process using it• No assumptions are made about relative process
speeds or number of processes• A process remains inside its critical section for a
finite time only
Mutual Exclusion - software approaches
First attempt
Processes P0 and P1, global variable turn
If turn = 0, P0 can enter its critical section
If turn = 1, P1 can enter its critical section
while (turn != 0) /* do nothing */ ; /* critical section */; turn = 1;
First attempt
Each process enters its critical section and then transfers the access (by changing the value of turn) to the other process.
busy waiting- while waiting to enter the critical section the process repeatedly checks the status of its permission (reads the value of turn) guarantees mutual exclusion
Drawbacksprocesses must strictly alternate reducing the speed of executionif one process fails the other is permanently blocked.
Second attempt
Using a separate variable for each process whose contents determine whether a process is in use of its critical section or not
while (flag[1]) /* do nothing */ ; flag[0] = true; /* critical section */; flag[0] = false;
No mutual exclusion however, due to the possibility of interleaving the operations for status checking and status changing
Third Attempt
• Set flag to enter critical section before checking other processes
flag[0] = true; while (flag[1]) /* do nothing */ ; /* critical section */; flag[0] = false;
Third Attempt
• If another process is in the critical section when the flag is set, the process is blocked until the other process releases the critical section
• Deadlock is possible when two process set their flags to enter the critical section. Now each process must wait for the other process to release the critical section
Fourth Attempt
• A process sets its flag to indicate its desire to enter its critical section but is prepared to reset the flag
flag[0] = true; while (flag[1]) { flag[0] = false; /* delay */ ; flag[0] = true; } /* critical section */; flag[0] = false;.
Fourth Attempt
• This is not working due to the possibility of interleaving the operations for status changing and status checking.
• There is a situation when none of the processes would be able to enter its critical section, similar to the situations described above.
Correct Solution
• Each process gets a turn at the critical section
• If a process wants the critical section, it sets its flag and may have to wait for its turn
Dekker’s algorithm
flag[0] = true; //indicate the need to enter // critical section
while (flag[1]) //while the other process is // also entering
if (turn == 1) // if it is its turn { flag[0] = false; //reset the flag to false while (turn == 1) // wait while it is still
// its turn /* do nothing */ ; flag[0] = true; //indicate entering the
// critical section } /* critical section */;turn = 1; //give the turn to the other process flag [0] = false; //change status
Peterson’s algorithm
flag[0] = true; //indicate the need to // enter critical
sectionturn = 1; //grant the turn to the
// other processwhile (flag[1] && turn == 1) //mutual exclusion
/* do nothing */ /* critical section */;
flag [0] = false; //change status
Mutual Exclusion:Hardware Support
• Interrupt Disabling
– Disabling interrupts guarantees mutual exclusion
– Processor is limited in its ability to interleave programs
– Multiprocessing• disabling interrupts on one processor will
not guarantee mutual exclusion
Mutual Exclusion:Hardware Support
• Special Machine Instructions
• Performed in a single instruction cycle
• Not subject to interference from other instructions
– Reading and writing
– Reading and testing
Mutual Exclusion Machine Instructions
• Advantages
– Applicable to any number of processes on either a single processor or multiple processors sharing main memory
– It is simple and therefore easy to verify
– It can be used to support multiple critical sections
Mutual Exclusion Machine Instructions
• Disadvantages
– Busy-waiting consumes processor time
– Starvation is possible when a process leaves a critical section and more than one process is waiting.
– Deadlock• If a low priority process has the critical region
and a higher priority process needs, the higher priority process will obtain the processor to wait for the critical region
Semaphores
The setting:
• Special variable called a semaphore is used for signaling
• If a process is waiting for a signal, it is suspended until that signal is sent
• Wait and signal operations cannot be interrupted
• Queue is used to hold processes waiting on the semaphore
Semaphores
• Semaphore is a variable that has an integer value
– May be initialized to a nonnegative number
– Wait operation decrements the semaphore value
– Signal operation increments semaphore value
Semaphore types
• Binary semaphore - binary values 0 and 1.
• Strong semaphore - a semaphore whose definition includes the policy of first-in-first-out (FIFO) queue.
• Weak semaphore - a semaphore that does not specify the order in which processes are removed from the queue.
• Strong semaphores guarantee avoiding starvation.
Producer/Consumer Problem
• One or more producers are generating data and placing these in a buffer
• A single consumer is taking items out of the buffer one at time
• Only one producer or consumer may access the buffer at any one time
Consumer
consumer:while (true) { while (in <= out)
/*do nothing */;w = b[out];out++; /* consume item w */
}
Producer/Consumer Problem
• the consumer takes an item only if one is available– a semaphore that prevents the
consumer from reading when the buffer is empty (n = out - in)
• mutual exclusion is not ensured• solution:
– a semaphore that allows only one producer/consumer to perform write/read
Producer/Consumer Problem
s - semaphore for entering the critical sectiondelay - semaphore to ensure reading from non-empty buffer
Producer: Consumer:
produce(); wait(delay);wait (s); wait(s);
append(); take();signal(delay); signal(s); signal(s); consume();
Monitors
• Monitor is a software module• Chief characteristics
– Local data variables are accessible only by the monitor
– Process enters monitor by invoking one of its procedures
– Only one process may be executing in the monitor at a time
Monitors
• synchronization - condition variables contained within the monitor and accessible only from within the monitor.
– cwait(c)
– csignal(c)
• The advantage that monitors have over semaphores is that all of the synchronization functions are confined to the monitor.
Monitors
cwait(c): Suspend execution of the calling process on condition c. The monitor is now available for use by another process.
csignal(c): Resume execution of some process suspended after a cwait on the same condition. If there are several such processes, choose one of them; if there is no such process, do nothing.
Message Passing
• Enforce mutual exclusion
• Exchange information
send (destination, message)
receive (source, message)
Synchronization
• Sender and receiver may or may not be blocking (waiting for message)
• Blocking send, blocking receive– Both sender and receiver are blocked
until message is delivered– Called a rendezvous
Synchronization
• Nonblocking send, blocking receive
– Sender continues processing such as sending messages as quickly as possible
– Receiver is blocked until the requested message arrives
• Nonblocking send, nonblocking receive
– Neither party is required to wait
Addressing
• Direct addressing– send primitive includes a specific identifier
of the destination process– receive primitive could know ahead of time
which process a message is expected– receive primitive could use source
parameter to return a value when the receive operation has been performed
Addressing
• Indirect addressing– messages are sent to a shared data structure
consisting of queues– queues are called mailboxes– one process sends a message to the mailbox
and the other process picks up the message from the mailbox
Queuing Discipline
• First-in-first-out
• Specifying message priority
• Allow receiver to inspect message queue and select which message to receive next.
Mutual exclusion via messages
Process:
receive(mutex, msg);/* critical section
*/send(mutex, msg);
Main program:
create_mailbox(mutex);send(mutex,null);parbegin(P(1),…);
Readers/Writers Problem
• Any number of readers may simultaneously read the file
• Only one writer at a time may write to the file
• If a writer is writing to the file, no reader may read it
Readers have priority
Since the reading is not mutually exclusive, if someone is reading, any other can join the reading.
Writers are potentially subjected to starvation.
Semaphore: wsem - guarantees only one writer and mutually excludes reading and writing.
Readers have priority
• The algorithm:
• Only the first reader and each writer wait on wsem.
• The last reader and each writer signal wsem.
• Readers count their number in a variable readcount. To prevent simultaneous updating, they use a semaphore x
Initially wsem and x are set to 1, readcount is 0.
/* program readerswriters */int readcount;
semaphore x = 1, wsem = 1;
/* main */void main();{ readcount = 0; parbegin (reader, writer);
}
/* readers */wait(x);readcount++;if (readcount == 1) wait (wsem);signal(x);READUNIT();wait(x);readcount--;if (readcount == 0) signal(wsem);signal(x);
/* writers */wait(wsem);WRITEUNIT();
signal(wsem);
Writers have priority
The first writer that comes blocks the subsequent readers from joining the reading pool until all writers finish their job.
rsem - to prevent subsequent readers from joining the reading pool. It is set by the first writer, and released by the last writer
y - to prevent simultaneous updating of writecount
z - to queue the subsequent readers
/* program readerswriters */int readcount;
semaphore x = 1, y = 1, z = 1, wsem = 1, rsem = 1;
/* main */void main();{ readcount = writecount = 0; parbegin (reader, writer);
}
/* readers */wait(z);wait(rsem);wait(x);readcount++;if (readcount == 1) wait (wsem);signal(x);signal(rsem);signal(z);READUNIT();wait(x);readcount--;if (readcount == 0) signal(wsem);
signal(x);
/* writers */wait(y);writecount++;if (writecount == 1) wait (rsem);signal(y);wait(wsem);WRITEUNIT();signal(wsem);wait(y);writecount--;if (writecount == 0) signal(rsem);signal(y);
Alternative solution with messages
• The basic idea:
• Send message to request access
• Receive message that grants the access
• Do the jib
• Send message to indicate finished job.
Controller process
readrequest queue
writerequest queue
finished queue
a variable count is used for scheduling.
Writers have priority
count
Count > 0Only readers in action.
At each finished message count is decremented by 1.
Count < 0At least one writer is waiting. The controller clears the finished queue, incrementing count until it becomes 0.
Count = 0The pending writer is granted access. The controller waits to receive a finished message, before proceeding. Count is set to 100.