- A process is a program that is being run
- Each process executes (runs) independently from each other
- Processes can be executed simultaneously by the computer
- In the figure, the instructions at the arrow in both processes
may be executed simultaneously (assuming we have parallel hardware)
- (NOTE: computers execute assembler instructions, so although the figure shows high level language constructs, you know from CS255 how these constructs are transformed. Multiple assembler instructions are being executed simultaneously)
- In the figure, the instructions at the arrow in both processes
may be executed simultaneously (assuming we have parallel hardware)
- Do not share instruction code
- Do not share variables
- Processes may
share a minimum amount of information that
allow them to communicate with each other through
the operating system kernel using a
system call
(i.e., with the aid of the Operating System)
- E.g., UNIX processes share file descriptors which them to create pipes to communicate with each other.
- Whenever processes need to communicate with one another,
they must invoke some system call.
- Recall that a system call will always save the context of
the invking process (and at the end, it will restore
the context of (the same or another) process.
Context switching is a very expensive operation (save registers !)
- A heavy weight exection unit that do not share
- A thread is a flow of control (or line of execution)
inside a process
There is at least one thread within every process (otherwise, the process will not run :-))
- "Traditional" processes are single threaded
A single threaded process has exactly one thread...
- A multi-threaded program has more than one thread
- So a multi-threaded program has multiple flows of control
In other words:
- The computer can be simultaneously executing at multiple places inside the same program !
- Pictorially:
- The computer executes two instructions from process 1 and three instructions from process 2 simultaneously (assuming we have sufficient parallel hardware)
- Wait a minute.... what is the big deal with threads ? Aren't they processes inside a process ???
- Share instruction code
- Share all global variables in the program
- Do not share their local variables
- Threads can communicate with one another through the use (reading and writing) of global variables (since variables are stored in memory, this method of communication is also known as shared memory)
- Threads do not need to invoke any system calls to
communicate with each other.
Many computer vendors have developed their own thread application programming interface to allow programmers to write multi-threaded programs.
Sun Microsystems has implemented the Solaris threads API (and it is still available)
When a multi-threaded program is written on one platform, it usually cannot be compiled on another (due to differences in the APIs)
To promote portability, the POSIX thread standard was proposed and adopted.
- To use the POSIX threads (or "pthreads" for short), include
the header file:
#include <pthread.h> - And use the compiler options:
cc -mt [other flags] file... -lpthread [other libraries]
Syntax:
int pthread_create(pthread_t *thread,
const pthread_attr_t *attr,
void *(*start_routine, void*),
void *arg);
Input parameters:
- attr = attributes of the created thread (set desired bits using
pthread_attr_init() calls)
- start_routine = starting location of the execution of the new thread
(it is a function)
This function can have (exactly) one parameter (or argument)
- arg = argument for the start_routine function (similar to argc and argv of the main thread)
Output parameter:
- thread = thread ID.
Upon successful completion, pthread_create() stores the ID of the created thread in the location referenced by thread.
Return value:
- 0 if successful
- None zero, if error (see errno for detail)
Usage:
pthread_t TID; /* Thread ID - used for signaling */
pthread_attr_t attr; /* Thread attribute values for creation */
/* Clear out thread attributes (use default values) */
if (pthread_attr_init(&attr) != 0)
{ perror("Thread_Create: pthread_attr_init");
exit(1);
}
.... set various thread attributes if needed (often not)
if (pthread_create(&TID, &attr, my_proc, param) != 0)
{ perror("Thread_Create: pthread_create");
exit(1);
}
Elsewhere in the program:
void *my_proc(void *) param) <---- new thread will begin
{ execution with this function
....
}
|
- Contention Scope:
- PTHREAD_SCOPE_SYSTEM: system scheduling contention scope.
This thread contents for the CPU with other processes in the system (is permanently bounded to an "LWP" - a schedule unit in the operating system kernel). Such a thread is called a bound thread.
- PTHREAD_SCOPE_PROCESS: process scheduling contention scope.
This thread contents for the CPU with other "process scoped" threads. Such a thread is called a unbound thread.
- Default contention scope is PTHREAD_SCOPE_PROCESS
- PTHREAD_SCOPE_SYSTEM: system scheduling contention scope.
- Detach State:
- PTHREAD_CREATE_DETACHED: thread is created "detached"
You cannot invoke pthread_detach() (detach again ?) and pthread_join() on detached threads Detached threads run independently from other threads and cannot wait for other threads using pthread_join().
- PTHREAD_CREATE_JOINABLE: thread is created joinable
Joinable threads may call pthread_join() to wait on another thread upon its termination (usually to pass some return value to another thread - is similar to the join system call (cs351))
- Default contention scope is PTHREAD_CREATE_JOINABLE
- PTHREAD_CREATE_DETACHED: thread is created "detached"
- Stack size:
- You can set the runtime stack size used by the thread
- Stack address:
- You can choose to set the stack at some location in memory (best not !)
- Scheduling Policy:
- You can set the runtime priority of a thread
- And so on....
- I suggest that you don't try anything funny and use the default values
obtained by:
int pthread_attr_init(pthread_attr_t *attr)
- The most important aspect of parallel programming is
synchronization among the various parallel executing agents
that access a common resource.
Some access operations are conflicting and cannot be executed simulateneously
One common conflicting operations are:
- Reading by one thread and writing by another thread
- Writing by one thread and writing by another thread
- Recall that the global variables can be accessed by all threads
- Recall that threads executes simultaneously, meaning
the (assembler) instructions at multiple places in the program
are executed (by multiple CPUs)
- Consider the following program with 2 paralle threads
of execution that is about to the same (global) variables:
Suppose the variable "balance" contains the value 1000.
"Normally", when both threads finish with their operations on the "balance" variable, the new values of "balance" will be 900.
However, it is possible that the CPUs execute the assembler instructions interleaved.... (afterall, each CPU executes the instructions independently from one another).
Hence, one possible execution ordering is the following:
CPU 1 CPU 2 --------------------- ------------------------ move.l balance, D0 (D0 = 1000) move.l balance, D0 (D0 = 1000) add.l #100, D0 (D0 = 1100) sub.l #200, D0 (D0 = 800) move.l D0, balance, (balance = 1100) move.l D0, balance, (balance = 800)And when both threads finish with their access of the "balance" variable, the resulting value of balance is 800 ! - Another execution order of the threads can produce the result
balance = 1100.... (try to figure out how)
- Obviously, there is a need to ensure that the parallel thread
execution will not produce results that is different
from the "normal" result.
- This problem when parallel thread execution can produce abnormal results is called (thread) synchronization problem
From CS351, you may have learned the following common synchronization methods:
- Mutex (or Mutually exclusive locks)
- Read/Write Locks
- Monitor
- Binary semaphore
- Counting semaphore
- Conditional variable (probably not)...
- Mutex (or Mutually exclusive locks)
- Read-write lock
- Conditional variable (a test-and-set operation)
So it is no big deal that PThreads do not implement them...
- A mutex is an object (remember from CS170: variables + methods)
with 2 (3 if you count creation as an operation) operations.
- The operations on mutex objects are written with special assembler
codes so that when one of the operations is invoked by some thread,
no other threads can invoke any mutex operations
until that thread finishes with the mutex call.
(There are different way to achieve this "atomic" execution effect and will not discussed here. If you are interested, read more on "interrupt disable", "test-and-set" instructions)
- Creation - initially, a mutex is always unlocked
- lock - change a mutex from unlocked to locked.
If the mutex was in a locked state, the call
will cause the invoking thread to "block" (stop execution)
until the mutex becomes unlocked
- unlock - change a mutex from locked to unlocked. Only the thread that currently holding the lock can unlock a mutex.
- Defining a mutex variable "x":
pthread_mutex_t *x;
- Initializing a mutex variable:
int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *attr); Example: pthread_mutex_init(&x, NULL); /* Default initialization */
- Locking a mutex:
int pthread_mutex_lock(pthread_mutex_t *mutex); Example: pthread_mutex_lock(&x);
- Unlocking a mutex:
int pthread_mutex_unlock(pthread_mutex_t *mutex); Example: pthread_mutex_unlock(&x);
A common usage of mutex is to synchronize updates to shared (global) variables
Whenever a thread want to read or write a shared variable, it must enclose the operation by a "lock - unlock" pair.
Example:
The atomic execution of the mutex lock function prevents multiple threads from executing instructions that access the common variable.
- Make sure you unlock a mutex after you are done with
accessing the share variable(s).
A common error is to forget the unlock call... the result is "deadlock" - you program hangs (no progress)
These are very similar to mutex, except that there are 2 types of locks: read and write.
Read and write lock operations conflict, one write and another write lock operations also conflict, but 2 read lock operations can be performed at the same time
Read/Write Lock API:
int pthread_rwlock_init(pthread_rwlock_t *rwlock, const pthread_rwlockattr_t *attr); int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock); int pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock);
The "test-and-set(x)" operation on a (memory) variable "x" performs the following operations atomically:
- First, save the (original) value of "x" into an auxiliary register
- Store the value 1 into "x"
- Return the (original) auxiliary value of "x"
The test-and-set operation is a powerful operation that can be use to implement all shared memory synchronization primitives.
- Mutex initialization:
pthread_mutex_init(&x) <----> x = 0;
- Mutex lock:
pthread_mutex_lock(&x) <----> Loop: if ( test-and-set(x) == 1 ) goto Loop;
- Mutex unlock:
pthread_mutex_unlock(&x) <----> x = 0;
- The conditional variable is the PThread's equivalent of
the test-and-set operation
- A conditional variable is initialized by using:
int pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *attr); Example: pthread_cond_t x; pthread_cond_init(&x, NULL); - To implement the test-and-set operation, a conditional
variable is always used in conjunction with
a mutex variable.
- There are 2 operations on conditional variables:
- wait (wait for the condition to become true)
- signal (signal that the condition has become true)
- pthread_cond_wait():
used to block a thread on a condition variable
(block means: put it to sleep, disallow it to run until further notice.
If you recall from CS355 or CS351, you must realise that you would
use a process queue to hold the "PCBs" of blocked threads)
int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);Atomically:- Block the thread on the conditional variable cond
- Unlock the mutex variable mutex
- NOTE: mutex must be locked when pthread_cond_wait() is called, or else, anything (unpredictable results) can happen...
- pthread_cond_signal():
used to unblock a thread that was block on the condition variable
(i.e., take one thread PCB from the queue associated with the
conditional variable and make that thread "runnable")
int pthread_cond_wait(pthread_cond_t *cond);
- I will delay the use of Conditional Variable after I discuss binary semaphores
- Semaphore:
sema.phore \'sem-*-.fo-(*)r, -.fo.(*)r\ n [Gk se-ma sign, signal + ISV -phore] 1: an apparatus for visual signaling (as by the position of one or more movable arms) 2: a system of visual signaling by two flags held one in each hand
- The Binary Semaphore was invented by E. W. Dijkstra -
a Dutch pioneer in Computer Science while he was
directing the T.H.E. (Technical University of Eindhoven)
Operating System project
- Dijkstra developed the semaphore concept when he studied the
exclusive resource access problem:
- Conflicting operations on a common resource (global variable)
must happen serially - complete one operation before
allowing another operation to even begin....
- He notice that the real world already has a solution: Trains !
- A train entering a "critical section" must pass a "semaphore" (signalling) device
- If the semaphore is up, the train can pass, but as soon as the train crosses the semaphore, it trigger all semaphore signals to go down.
- The semaphre signals will only be raised (to up) after the train leaves the critical section (triggers the "leave-trigger").
- Conflicting operations on a common resource (global variable)
must happen serially - complete one operation before
allowing another operation to even begin....
- The binary semaphore is an object that can take on
2 values: 0 (down) and 1 (up)
- There are 2 operations on a semaphore:
- P(s): "Pee semaphore s"
If s = 1 (up), P(s) returns immediately and the thread that executes the P(s) operation continues - this is the success case (no train in the critical section)
If s = 0 (down), P(s) blocks - the thread executing the P(s) operation will be made unrunnable (not ready to run) and put in a queue that is associated with the semaphore s.
Note: the "P" operation is the acronym for Pass - Dutch: Passeren)
- V(s): "Vee semaphore s"
Set s = 1 and if the queue that is associated with the semaphore s is not empty, then reactivate a block process from that queue
Note: V(s) always succeeds (leaving the critical section can always be done).
Note: the "V" operation is the acronym for leaVe :-) - Just kidding, you need to know Dutch to find the acronym: Verlaten in Dutch means to leave.... hence the V - remember, Dijkstra was a Dutch...)
- P(s): "Pee semaphore s"
- Creating a binary semaphore:
typedef struct BIN_SEMA { pthread_cond_t cv; /* cond. variable used to block thread */ pthread_mutex_t mutex; /* The mutex used in association with cv */ /* The mutex variable prevents concurrent access to the (shared) variable flag (next variable) */ int flag; /* Semaphore state: 0 = down, 1 = up */ } bin_sema; void BinSemaInit(bin_sema **s, int value) { if (value >= 1 || value < 0) value = 1; /* make sure it's 0 or 1 */ *s = (bin_sema *) malloc(sizeof(bin_sema)); /* Create the sema struct */ pthread_mutex_init(&((*s)->mutex), NULL); /* Init mutex */ pthread_cond_init(&((*s)->cv), NULL); /* Init cond. variable */ (*s)->flag = value; /* Set flag value */ } - The P-operation:
void BinSemaP(bin_sema *s) { pthread_mutex_lock(&(s->mutex)); /* Gain exclusive access to s->flag */ while (s->flag == 0) /* If flag == 1 then skip while loop */ pthread_cond_wait(&(s->cv), &(s->mutex) ); /* flag = 0 in while body */ /* Block the thread on the conditional variable cv... Note that we must RELEASE the mutex that was locked previously ! This thread will be restarted by another thread that performs a V operation */ /* ----------------------------------------------------------- When you exit the while loop, s->flag == 1 and this thread has successfully pass semaphore... ----------------------------------------------------------- */ s->flag = 0; /* This will cause other thread that executes P() to block... */ pthread_mutex_unlock(&(s->mutex)); /* Done with updating flag, release the mutex so that other threads can access the flag variable (they will find flag == 0 and block, but before they can make this decision, they need access to "flag") */ } - The V-operation:
void BinSemaV(bin_sema *s) { pthread_mutex_lock(&(s->mutex)); /* Gain exclusive access to s->flag */ pthread_cond_signal(&(s->cv)); /* Restart some thread that was blocked on s->cv - if there was not thread blocked on - cv, this operation does absolutely - nothing... */ s->flag = 1; /* Update semaphore state to Up */ pthread_mutex_unlock(&(s->mutex)); /* Done, release exclusive access */ }
Semaphores are more powerful than mutex locks - anywhere you can use a mutex to ensure synchronization, you can also use a semaphore (but not vice versa).
Here is an example of using binary semaphores to access shared variables:
Thread 1: Thread 2: BinSemaP(s); BinSemaP(s); balance = balance + 100; balance = balance - 200; BinSemaV(s); BinSemaV(s);
The famous "Reader and Writer" synchronization problem can be solved with semaphores, but not with mutexes:
share variable x Reader sums all values written by writer exactly once Use 2 semaphores: ReadSema and WriteSema BinSemaInit(ReadSema, 0); /* Block reader until writer has written */ BinSemaInit(WriteSema, 1); /* Allow writer to start first */ Reader Thread: Write thread: BinSemaP(ReadSema); BinSemaP(WriteSema); sum = sum + x; x = new_value(); BinSemaV(WriteSema); BinSemaV(ReadSema);
- A short tutorial on pthreads: click here
- A longer tutorial on pthreads: click here