Scribd
Upload
106 views29 pages

An Introduction To Programming With Threads

This document provides an introduction to programming with threads. It discusses what threads are, why they are useful for exploiting parallelism, and common thread mechanisms like creation, mutual exclusion, waiting for events, and interrupting threads. It provides examples of thread primitives like fork, join, locks, and condition variables. It also covers topics like avoiding deadlocks, differences between kernel and user threads, and ensuring thread-safe libraries.

Uploaded by

Prudhvinadh Kopparapu
Copyright
© Attribution Non-Commercial (BY-NC)
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
106 views29 pages

An Introduction To Programming With Threads

This document provides an introduction to programming with threads. It discusses what threads are, why they are useful for exploiting parallelism, and common thread mechanisms like creation, mutual exclusion, waiting for events, and interrupting threads. It provides examples of thread primitives like fork, join, locks, and condition variables. It also covers topics like avoiding deadlocks, differences between kernel and user threads, and ensuring thread-safe libraries.

Uploaded by

Prudhvinadh Kopparapu
Copyright
© Attribution Non-Commercial (BY-NC)
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/ 29

An Introduction to Programming with Threads

Resources

Birrell - "An Introduction to Programming with Threads" Silberschatz et al., 7th ed, Chapter 4

Threads
A thread is a single sequential flow of control
A process can have many threads and a single address space Threads share memory and, hence, need to cooperate to produce correct results Thread has thread specific data (registers, stack pointer, program counter)

Threads continued..

Why use threads


Threads are useful because of real-world parallelism:
input/output devices (flesh or silicon) may be slow but are independent -> overlap IO and computation distributed systems have many computing entities multi-processors/multi-core are becoming more common better resource sharing & utilization then processes

Thread Mechanisms
Birrell identifies four mechanisms used in threading systems:
thread creation mutual exclusion waiting for events interrupting a threads wait

In most mechanisms in current use, only the first three are covered In the paper - primitives used abstract, not derived from actual threading system or programming language!

Example Thread Primitives


Thread creation
Thread type Fork(proc, args) returns thread Join(thread) returns value

Mutual Exclusion
Mutex type Lock(mutex), a block-structured language construct in this lecture

Example Thread Primitives


Condition Variables
Condition type Wait(mutex, condition) Signal(condition) Broadcast(condition)

Fork, Wait, Signal, etc. are not to be confused with the UNIX fork, wait, signal, etc. calls

Creation Example
{ Thread thread1; thread1 = Fork(safe_insert, 4); safe_insert(6);

Join(thread1); // Optional
}

Mutex Example
list<int> my_list; Mutex m; void safe_insert(int i) { Lock(m) { my_list.insert(i); } }

Condition Variables
Mutexes are used to control access to shared data only one thread can execute inside a Lock clause other threads who try to Lock, are blocked until the mutex is unlocked Condition variables are used to wait for specific events free memory is getting low, wake up the garbage collector thread 10,000 clock ticks have elapsed, update that window new data arrived in the I/O port, process it Could we do the same with mutexes? (think about it and well get back to it)

Condition Variable Example


Mutex io_mutex; Condition non_empty; ... Consumer: Lock (io_mutex) { while (port.empty()) Wait(io_mutex, non_empty); process_data(port.first_in()); }

Producer: Lock (io_mutex) { port.add_data(); Signal(non_empty); }

Condition Variables Semantics


Each condition variable is associated with a single mutex Wait atomically unlocks the mutex and blocks the thread Signal awakes a blocked thread
the thread is awoken inside Wait tries to lock the mutex when it (finally) succeeds, it returns from the Wait

Doesnt this sound complex? Why do we do it?


the idea is that the condition of the condition variable depends on data protected by the mutex

Condition Variable Example


Mutex io_mutex; Condition non_empty; ... Consumer: Lock (io_mutex) { while (port.empty()) Wait(io_mutex, non_empty); process_data(port.first_in()); }

Producer: Lock (io_mutex) { port.add_data(); Signal(non_empty); }

Couldnt We Do the Same with Plain Communication?


Mutex io_mutex; ... Consumer: Lock (io_mutex) { while (port.empty()) go_to_sleep(non_empty); process_data(port.first_in()); } Producer: Lock (io_mutex) { port.add_data(); wake_up(non_empty); }

Whats wrong with this? What if we dont lock the mutex (or unlock it before going to sleep)?

Mutexes and Condition Variables


Mutexes and condition variables serve different purposes
Mutex: exclusive access Condition variable: long waits

Question: Isnt it weird to have both mutexes and condition variables? Couldnt a single mechanism suffice? Answer:

Use of Mutexes and Condition Variables


Protect shared mutable data:
void insert(int i) { Element *e = new Element(i); e->next = head; head = e; }

What happens if this code is run in two different threads with no mutual exclusion?

Using Condition Variables


Mutex io_mutex; Condition non_empty; ... Consumer: Lock (io_mutex) { while (port.empty()) Wait(io_mutex, non_empty); process_data(port.first_in()); } Producer: Lock (io_mutex) { port.add_data(); Signal(non_empty); }

Why use while instead of if? (think of many consumers, simplicity of coding producer)

Readers/Writers Locking
Mutex counter_mutex; Condition read_phase, write_phase; int readers = 0; Reader: Lock(counter_mutex) { while (readers == -1) Wait(counter_mutex, read_phase); readers++; } ... //read data Lock(counter_mutex) { readers--; if (readers == 0) Signal(write_phase); }

Writer: Lock(counter_mutex) { while (readers != 0) Wait(counter_mutex, write_phase); readers = -1; } ... //write data Lock(counter_mutex) { readers = 0; Broadcast(read_phase); Signal(write_phase); }

Comments on Readers/Writers Example


Invariant: readers >= -1 Note the use of Broadcast The example could be simplified by using a single condition variable for phase changes less efficient, easier to get wrong Note that a writer signals all potential readers and one potential writer. Not all can proceed, however (spurious wake-ups) Unnecessary lock conflicts may arise (especially for multiprocessors): both readers and writers signal condition variables while still holding the corresponding mutexes Broadcast wakes up many readers that will contend for a mutex

Readers/Writers Example
Reader:
Lock(mutex) { while (writer) Wait(mutex, read_phase) readers++; } // read data Lock(mutex) { readers--; if (readers == 0) Signal(write_phase); }

Writer:
Lock(mutex) { while (readers !=0 || writer) Wait(mutex, write_phase) writer = true; } // write data Lock(mutex) { writer = false; Broadcast(read_phase); Signal(write_phase); }

Avoiding Unnecessary Wake-ups


Mutex counter_mutex; Condition read_phase, write_phase; int readers = 0, waiting_readers = 0; Reader: Lock(counter_mutex) { waiting_readers++; while (readers == -1) Wait(counter_mutex, read_phase); waiting_readers--; readers++; } ... //read data Lock(counter_mutex) { readers--; if (readers == 0) Signal(write_phase); } Writer: Lock(counter_mutex) { while (readers != 0) Wait(counter_mutex, write_phase); readers = -1; } ... //write data Lock(counter_mutex) { readers = 0; if (waiting_readers > 0) Broadcast(read_phase); else Signal(write_phase); }

Problems With This Solution


Explicit scheduling: readers always have priority
may lead to starvation (if there are always readers) fix: make the scheduling protocol more complicated than it is now

To Do: Think about avoiding the problem of waking up readers that will contend for a single mutex if executed on multiple processors

Discussion Example
Two kinds of threads, red and green, are accessing a critical section. The critical section may be accessed by at most three threads of any kind at a time. The red threads have priority over the green threads.
Discuss the CS_enter and CS_exit code. Why do we need the red_waiting variable? Which condition variable should be signalled when? Can we have only one condition variable?

Mutex m; Condition red_cond, green_cond; int red_waiting = 0; int green = 0, red = 0;

Red: Lock(m) { // ??? while (green + red == 3) Wait(m, red_cond); red++; // ??? } ... //access data Lock(m) { red--; // ??? // ??? // ??? }

Green: Lock(m) { while (green + red == 3 || red_waiting != 0) Wait(m, green_cond); green++; } ... //access data Lock(mutex) { green--; // ??? // ??? // ??? }

Deadlocks (brief)
Well talk more later for now beware of deadlocks Examples: A locks M1, B locks M2, A blocks on M2, B blocks on M1 Similar examples with condition variables and mutexes Techniques for avoiding deadlocks: Fine grained locking Two-phase locking: acquire all the locks youll ever need up front, release all locks if you fail to acquire any one very good technique for some applications, but generally too restrictive Order locks and acquire them in order (e.g., all threads first acquire M1, then M2)

MT and fork() and Thread-Safe libraries


fork semantics
forkall (e.g., Solaris fork()) forkone (e.g., Solaris fork1(), POSIX fork()) ensure no mutexes needed by child process are held by other threads in parent process (e.g., pthread_atfork)

Issue: mutex maybe be locked by parent at fork time -> child process will get its own copy of mutex with state LOCKED and noone to unlock it!

not all libraries are thread-safe


must check to ensure use may have thread-safe alternatives

Scope of multithreading
LWPs, kernel and user threads kernel-level threads supported by the kernel
Solaris, Linux, Windows XP/2000 all scheduling, synchronization, thread structures maintained in kernel could write apps using kernel threads, but would have to go to kernel for everything

user-level threads supported by a user-level library


Pthreads, Java threads, Win32 sched. & synch can often be done fully in user space; kernel doesnt need to know there are many user threads problem with blocking on a system call

Light Weight Processes - LWP


These are virtual CPUs, can be multiple per process The scheduler of a threads library schedules user-level threads to these virtual CPUs kernel threads implement LWPs => visible to the kernel, and can be scheduled sometimes LWP & kernel threads used interchangeably, but there can be kernel threads without LWPs

You might also like