Scribd
Upload
12 views27 pages

Synchronization & Implementation Issues

The document discusses various synchronization and implementation issues in multi-threaded environments, including problems like performance, priority inversion, starvation, and deadlock. It outlines solutions such as priority inheritance for priority inversion and strategies for deadlock prevention and resolution. Additionally, it highlights synchronization bugs and denial of service problems that can arise from improper handling of shared resources.

Uploaded by

Tuấn Hoàng Văn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
12 views27 pages

Synchronization & Implementation Issues

The document discusses various synchronization and implementation issues in multi-threaded environments, including problems like performance, priority inversion, starvation, and deadlock. It outlines solutions such as priority inheritance for priority inversion and strategies for deadlock prevention and resolution. Additionally, it highlights synchronization bugs and denial of service problems that can arise from improper handling of shared resources.

Uploaded by

Tuấn Hoàng Văn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 27

Synchronization &

Implementation Issues
Synchronization Problems

Performance
Interaction with thread priorities
Starvation
Deadlock
Synchronization bugs
Heizenbugs
Service denial bugs
Performance

Blocking synchronization
Context switch if mutex is not available
But makes CPU available to others
Spinlock synchronization
Wastes CPU resources
But if mutex is available, or will be available soon, then we avoid the
context switch overhead
Hybrid Synchronization (Solaris)

Combines both worlds:


Start out with a spinlock
if mutex is available, enter C.S.
else spin, but...
Spin only for a limited time, if mutex is not available, then use
blocking synchronization

This is only relevant for multiprocessors!!


The Priority Inversion Problem

Priority = 20

Priority = 10

Priority = 5
Priority Inversion

Happens a lot
vxWorks problems in Pathfinder
Fundamental problem:
Low-priority thread holds lock, enters C.S.
Higher-priority thread blocks waiting for lock
A medium-priority thread comes along and
KA-BOOOOOM
Solution: Priority Inheritance

If low-priority thread holds lock


and
A high-priority thread requests lock
then
set low-priority thread’s priority to that of the high-priority
thread until it gives up lock.
The Priority Inversion Problem

Priority = 20

Priority = 10

Priority = 5
Priority = 20 Priority = 5
The Starvation Problem

If the synchronization solution is not well implemented,


a thread may starve:
Example:
A sempahore implemented in LIFO order (stack)
The Deadlock Problem

A situation where two or more threads are waiting each


other indefinitely
Happens a lot when mutexes are used, e.g. transaction
systems
Example

Thread 1 Thread 2

P(s1) P(s2)
… …
P(s2) P(s1)
… …
V(s1) V(s2)
V(s2) V(s1)
Problem Definition

Deadlocks occur when the processes are involved in a


cyclical wait
e.g.
Process one has printer, asks for tape
Process two has tape, asks for printer
(Classical definition, irrelevant in practice)
A More Relevant Example

lock(f2); lock(f1);
… …
lock(f1); lock(f2);
Deadlock is Bad

It prevents processes from making progress


It requires intervention to break the deadlock
It reduces resource utilization
Solutions

Prevent deadlocks from happening


Allow deadlock and react
Do nothing (this is the most used in real life)
Deadlock Prevention

Impose a linear order on resources


Force processes to request resources in the given order
Deadlock never happens
But
Inflexible
Cannot scale to large programs/systems
Example Revisited

…
lock(f2); <---- lock(f1);
… …
lock(f1); lock(f2);
Deadlock Prevention

If a thread is forced to wait for a mutex, it gives up all


mutex’es it holds and restarts later
Used in operating system kernels
Can be very tricky
You must ensure that you will not do any partial updates if forced to
give up mutexes
Need to be able to roll back updates
Need to figure out what to release if we will block
Bug Gallore!
Deadlock Resolution

Allow deadlock to happen


Analyze the situation
Pick a victim process and kill it
But
How to detect there is really a deadlock?
How to pick a victim?
Overhead
Example Revisited

lock(f2); lock(f1);
… …
lock(f1); lock(f2);
… …

Pick one process and kill it


How to Detect

Build a graph
Processes are vertices
An edge from process I to j if I wants a resource held by j.
If the graph has a cycle, there is deadlock
For Entertainment

See Banker’s algorithm for deadlock avoidance


Synchronization Bugs

Program may not protect all shared variables properly


Variables may have unpredictable values according to a
particular scheduling
Cannot repeat them easily -- Debugging nightmare
Heizenbugs
Example

P(s) P(s)
… …
V(s) V(s)
…
V(s)
Example

P(s); a++; // demonic


a++; // variable
V(s);
Denial of Service Problem

A safe solution but,


Liveness is not guaranteed
Examples:
C.S. solutions that do not ensure progress
A thread crashes in the middle of a C.S.
A thread gets caught up in a infinite loop inside C.S.
A thread does not clean up after itself
Example

P(s); P(s);

…return; V(s);

… char * p = 0; * p = 0;

… while(1) … ;
V(s);

You might also like