Download ppt

CMPT 300
Introduction to Operating
Systems
Operating Systems
Processes and Threads
© Janice Regan, CMPT 300, May 2007
0
What is a process?
 A process (active entity) is a program (static
entity) in execution, and includes

An address space, an area in memory (memory
location x to y) containing



List of instructions
Any required data
The stack for the program

Registers
 Other information (includes resources used, status of
I/O )
© Janice Regan, CMPT 300, May 2007
1
Multiprocessing shares memory
 When multiple
processes are sharing
the CPU the memory is
shared between them
250
Dispatcher
Process A

Each process can only
access it’s own area of
memory (program
image, stack, …)
 Pointers (stored in
registers) give the base
address and the length
or end address. (shown
here in # of words)
© Janice Regan, CMPT 300, May 2007
1000
4000
Process B
5000
7000
Process C
10000
2
Processes/Threads
 A process groups all resources needed to execute a program
 Our OS switches between processes and otherwise manages
processes, this incurs a significant overhead for each process
 Processes are useful for encapsulation and security.
 They cannot access each others memory space
 The resources they use are protected from other
processes
 This can be useful when processes are competing for
resources (different owners who want optimal turnaround)
 However, sometimes we want programs to be able to interact
and cooperate and even share memory space when they run,
(controlled by the same user, cooperating with each other).
The process model does not allow this.
© Janice Regan, CMPT 300, May 2007
3
Path of Execution
 A path of execution can be thought of as a
list of instructions in order they are
actually executed when a particular
process executes.
 Two different processes running the same
program can have different threads of
execution
 A thread follows a particular path of
execution through a program
© Janice Regan, CMPT 300, May 2007
4
What is a thread?
 A “lightweight process”
 Each thread has its own program image
 Program counter, registers
 Stack (path of execution), automatic data
 State
 Each thread in a particular process shares
 Program text, Global variables
 Files and other communication connections
 State (different from process state)
© Janice Regan, CMPT 300, May 2007
5
What is shared
Process
Shared
Process
control block
Thread 2
Thread 3
Thread control
block
Thread control
block
Thread ocntrol
block
REGISTERS
REGISTERS
REGSITERS
STACK
STACK
STACK
Includes
Automatic
variables
Includes
Automatic
variables
Includes
Automatic
variables
Thread 1
User address
space
Code
Global
variables
Heap
Static
variables
© Janice Regan, CMPT 300, May 2007
6
Resource ownership
 Separate the two main characteristics of a process,
Resource ownership/management and
Scheduling/execution.
 Resource ownership: Address space holding a
process image (program, data, state stored in
process control block), main memory, connections
to I/O devices, other hardware devices and other
processes (also stored in process control block)
 Owned by a process
 Shared by a thread
© Janice Regan, CMPT 300, May 2007
7
Scheduling, execution
 Separate the two main characteristics of a process,
Resource ownership/management and
Scheduling/execution.
 Scheduling/dispatching/execution
 Program counter, registers, stack, locally
declared (automatic variables) variables owned
by each thread within a process
 Follows an execution path through the program
image (trace through the code)
 Execution path is unique to each process, and
to each thread within a process
© Janice Regan, CMPT 300, May 2007
8
Multithreading: advantages
Multithreading: The ability of the operating
system to support more than one
concurrent thread of execution within any
given process
 Increases efficiency over using multiple
processes because


Fewer process context switches (using shared image)
Less thread context to save (program counter, local
thread specific variables, thread state)
 Takes less time to create/terminate a thread than a
process (less to copy)
© Janice Regan, CMPT 300, May 2007
9
Multithreading: disadvantages
 Sharing increases possibility of synchronization
problems
 Each thread can modify all variables in the memory
image (but cannot control order modifications are
done)
 All files and other communication connections are
shared. Reading in one thread, moves read
pointer
 Suspending a process means suspending several
threads to allow the image to be swapped
 If you fork a multithreaded process, what happens?
© Janice Regan, CMPT 300, May 2007
10
When threads are useful
 Multiprocessor systems (simultaneous execution of





different threads on multiple processors)
Foreground (display and input) and background work
(using a word processor, spreadsheet …)
Asynchronous processing (timed save in a word
processor, I/0 processing in background …)
Efficiency advantages of multiprocessing within on
process (one thread blocked, run another)
Modularization: different threads in the process taking
care of different modularized tasks (I/0 from/to various
sources/destinations …)
Good examples in your text
© Janice Regan, CMPT 300, May 2007
11
Implementing threads
 Two main approaches to implementation

User level threads (POSIX Pthreads)





Thread management is the responsibility of the user and occurs
completely in user mode.
Thread scheduling is user controlled, you can choose the best way
to schedule your own threads
Blocking system calls or page faults block all threads (not just one)
must wrapper the call so thread is not blocked if device is busy
Cannot take advantages of multiprocessors
Kernel level threads (Windows, newer Linux releases)




All thread management is done by the kernel
Requires mode switch to kernel to move between threads
API to the kernel thread facility provides users access through
system calls
O/S dependent
© Janice Regan, CMPT 300, May 2007
12
Process and Thread States
 We have discussed the possible states of a
process (running, blocked, ready, … ).
 Each thread in a process can have its own state.
The states have the same names but we must
remember that they refer to only one thread
 Consider a process that is in the running state. If
that process has multiple threads only one of its
threads will be in the running state, the others will
be in blocked state or in ready state
© Janice Regan, CMPT 300, May 2007
13
User Level Threads
User Space
T1
T1
T2
T3
Thread
Library
P
P
Kernel Space
© Janice Regan, CMPT 300, May 2007
14
User level threads
 The application does the thread management in user




space with the help of a thread library
The kernel is not aware that threads are being used
An application begins as a process with a single thread.
The application keeps its own thread table to keep track
of all threads it has created using the library routine
thread_create()
The application must use thread_yield() to ask the
scheduler (library) to switch to the another thread


No context switch or interrupt are needed (fast)
Cannot let the OS scheduler manage sharing between threads
because the OS (kernel level) does not know threads exist
© Janice Regan, CMPT 300, May 2007
15
Some possible situations
 The process is in running state, one
thread yields to another thread in the
same process
 The process is in ready state, one of the
process’s threads is in running state
 The process is blocked in blocked state,
one of the process’s threads is in running
state.
© Janice Regan, CMPT 300, May 2007
16
user –level thread multiprocessing
 The threaded application starts as a process containing




a single thread. The process is in the running state.
The application uses the user-level thread library to
create additional threads
When thread A begins to run it will enter the running
state. Thread A will continue until it calls thread_yield()
When thread_yield() executes it will place Thread A into
the ready state, place thread B into the running state
(formerly in waiting state) and start running thread B
The process is still in the running state
© Janice Regan, CMPT 300, May 2007
17
User level threads: timesharing
 The threaded application starts as a process containing a single




thread. The process is in the running state.
The application uses the user-level thread library to create
additional threads
Thread A (in process 1) has been executing for one process
timesharing quantum and the timer interrupt has transferred
control to the kernel.
The kernel does not know about the threads, it saves the context
of process 1 and moves process 1 to ready state, and starts
executing process 2
Thread A is still in running state even though process 1 is in
ready state
© Janice Regan, CMPT 300, May 2007
18
User level threads: blocking
 The threaded application starts as a process containing a
single thread. The process is in the running state.
 The application uses the user-level thread library to create
additional threads
 When thread A begins to run it will enter the running state.
Thread A makes an I/O system call.


Control is transferred to the kernel which blocks the process
Remember the kernel does not know about the threads
 Thread A is still in state running, even though the process
is in state blocked

It is not possible to run any part (any thread) of the blocked process
© Janice Regan, CMPT 300, May 2007
19
User level threads: advantages
 The process does not have to switch to
kernel mode to do thread management
 Scheduling is implemented by the
application (using the thread library) so
scheduling can be application specific
 User level thread libraries can be portable
(can run on more than one OS)
© Janice Regan, CMPT 300, May 2007
20
User level: disadvantages
 When one thread makes a system call which
causes it to be blocked, the entire process is
blocked (use jacketing to mitigate)
 A multithreaded application does not benefit
from multiprocessing or time sharing. (these
occur on a per process basis)
 When a multithreaded process calls fork()
should some or all threads be duplicated?

Not a simple question
© Janice Regan, CMPT 300, May 2007
21
Jacketing
 Convert blocking system calls to non-blocking
system calls
 Write a jacket routine that checks to see if the
blocking devise is presently busy

If the devise is busy and would block control is
passed to a different thread. Otherwise execute the
request
 When control returns from the other thread repeat
the previous step

Must have a system call to check if a blocking device is busy
(select)
© Janice Regan, CMPT 300, May 2007
22
Kernel-Level Threads
User Space
T1
P
Kernel Space
© Janice Regan, CMPT 300, May 2007
T2
T1
T3
P
23
Kernel-level threads
 Kernel maintains process control blocks describing each
process and thread control blocks describing each
thread
 Threads from the same process can be scheduled
independently. Scheduling can be done for threads
rather than just for processes.
 If one thread is blocked, the other threads in the process
are not blocked
 Switching threads requires a system call and is therefore
less efficient
© Janice Regan, CMPT 300, May 2007
24
Hello world for threads
 Process to be executed by each thread
that is created. When function returns
thread terminates
void *hola(void * arg)
{
int myid=*(int *) arg;
printf("Hello, world, I'm %d\n",myid);
return arg;
}
Author: Mark Hays <[email protected]>
http://math.arizona.edu/~swig/documentation/pthreads/
25
Creating Threads
pthread_t threads[NTHREADS];
int ids[NTHREADS];
/* holds thread info */
/* holds thread args */
for (worker=0; worker<NTHREADS; worker++) {
ids[worker]=worker;
if ( errcode = pthread_create (&threads[worker],
NULL,
/* default thread attributes */
hola,
/* start routine
*/
&ids[worker])) {
errexit(errcode,"pthread_create");
}
}
Author: Mark Hays <[email protected]>
http://math.arizona.edu/~swig/documentation/pthreads/
26
Waiting for threads to terminate
for (worker=0; worker<NTHREADS; worker++) {
/* wait for thread to terminate */
if (errcode=pthread_join(threads[worker],(void *) &status)) {
errexit(errcode,"pthread_join");
}
/* check thread's exit status and release its resources */
if (*status != worker) {
fprintf(stderr,"thread %d terminated abnormally\n",worker);
exit(1);
}
}
Author: Mark Hays <[email protected]>
http://math.arizona.edu/~swig/documentation/pthreads/
27