Introduction to Object Technology
Download
Report
Transcript Introduction to Object Technology
Concurrency: Deadlock and
Starvation
Chapter 6
Revision
• Describe three necessary conditions for
deadlock
• Which condition is the result of the three
necessary conditions
• Deadlock avoidance makes sure that at
least one of the conditions does not exist
in the system (TRUE/FALSE)
• An unsafe state is a deadlocked state
(T/F)
Deadlock Avoidance
• Maximum resource requirement must be
stated in advance
• Processes under consideration must be
independent; no synchronization
requirements
• There must be a fixed number of
resources to allocate
• No process may exit while holding
resources
Deadlock Detection
• OS can perform deadlock detection to
detect and break deadlocks
• Detection can be carried out on each
resource request
• Allocation matrix, Available vector and
Request matrix are defined
• Mark processes that are not deadlocked
• Begin by marking zero rows in
Allocation matrix
Deadlock Detection
• Initialize W = A
• Find an ‘i’ such that process ‘i’ is currently
unmarked
• Determine if ith row of Q is less than or equal
to W (for all elements), if no, EXIT
• If yes, mark process ‘i’ and set W = W+A for
all elements in this row and go back to find
next unmarked process
• At the end, any unmarked process is
deadlocked
Deadlock Detection
P4 is marked first; P3 is taken; new W is 00011
P1 and P2 fail the test Q<W so they are deadlocked
Strategies once Deadlock
Detected
1. Abort all deadlocked processes
2. Back up each deadlocked process to some
previously defined checkpoint, and restart all
process
•
original deadlock may occur
3. Successively abort deadlocked processes
until deadlock no longer exists
4. Successively preempt resources until
deadlock no longer exists
Selection Criteria for
Deadlocked Processes(3&4)
• Least amount of processor time
consumed so far
• Least number of lines of output
produced so far
• Most estimated time remaining
• Least total resources allocated so far
• Lowest priority
Dining Philosophers
• Five philosophers are in deep thought sitting
around a dining table
• When they get hungry, they try to eat the
spaghetti
• There is only one fork to the left of each
philosopher
• Each philosopher must acquire two forks to eat
• One philosopher can begin eating if the
neighbour to the right has put down the fork
• No deadlock, no snatching, no starvation
Dining Philosophers Problem
Solution With Semaphores
•
•
•
•
•
•
•
•
•
•
•
•
•
•
semaphore fork[5] = {1};
void philosopher(int i)
{
while (true)
{
think();
wait(fork[i]);
wait(fork[(i+1) mod 5);
eat();
signal(fork[(i+1) mod 5);
signal(fork[i]);
}
}
All philosophers may starve to death!! Why??
UNIX Concurrency
Mechanisms
•
•
•
•
•
Pipes
Messages
Shared memory
Semaphores
Signals
Pipes
• Based on producer-consumer model
• A pipe is a FIFO queue written by one
process and read by another
• Writing process is blocked if no room
• Mutual exclusion is enforced by UNIX
• Named pipes can be shared by unrelated
processes as well
Messages
• Each process has a “mailbox”, an
associated message queue
• System calls are provided for message
passing
• Process sending message to a full queue
is suspended
Shared Memory and
Semaphores
• Common block of virtual memory shared by
multiple processes
• Fastest form of IPC
• UNIX kernel handles the semaphore
operations atomically
• A semaphore contains
– Current value
– PID of last process that accessed it
– Number of processes waiting
• System calls are provided to handle
semaphores
Signals
• A signal informs a process about an
event
• Signals do not have priorities
• Some signals in UNIX:
– SIGFPT: Floating point exception
– SIGALARM: Wake up after a time period
– SIGBUS: Bus error
Solaris Thread
Synchronization Primitives
1.
2.
3.
4.
•
•
•
Mutual exclusion (mutex) locks
Semaphores
Multiple readers, single writer locks
Condition variables
Implemented in KLT and ULT
Once created, either enter or release
Kernel does not enforce mutual exclusion
and unlocking on abort of threads
Solaris Mutex Locks and
Semaphores
• If a thread has locked a mutex, only this
thread will unlock it
• If another thread approaches the mutex,
it will be either blocked or wait in a spin
wait loop
• Use mutex_tryenter() to do busy waiting
• Solaris provides sema_P(), sema_v() and
sema_tryp() primitives for semaphores
Readers/Writer and Condition
Variables
• Readers/writer lock allows read-only
access for an object protected by this
lock
• If a thread is writing, all others must
wait
• Condition variables are used with mutex
locks
• Wait until a condition is true
Windows 2000 Concurrency
Mechanisms
1.
2.
3.
4.
5.
6.
7.
8.
9.
Process
Thread
File
Console input
File change notification
Mutex
Semaphore
Event
Waitable timer
W2K Summary
• Objects 5 through 9 are designed for
supporting synchronization
• Each of these objects can be in a
signaled or unsignaled state
• A thread issues wait request to W2K,
using the handle of the object
• When an object enters signaled state,
threads waiting on it are released
W2K Example
• A thread requests wait on a file that is
currently open
• The thread is blocked
• The file is set to signaled state when the
I/O operation completes
• The waiting thread is released