Transcript CS350-04-impl-threads.ppt

Implementing Processes and
Threads
© 2004, D. J. Foreman
1
Required Software for Threads
 UNIX
(Linux, OpenBSD, FreeBSD,
Solaris)
Exported POSIX API or use "Pthreads" API
■ gcc or g++ with -lpthread -lposix4 -lthread
■
 Windows
(98/ME/NT/XP)
WIN32 API – not POSIX compliant
■ Pthreads.DLL – freeware
■
• sources.redhat.com/pthreads-win32
• Copy pthread.dll to C:\windows
• Keep .h files wherever you want them
© 2004, D. J. Foreman
2
Exploring the Abstraction
Loc 0
Loc 0
User i
Processes & RAM
Loc n
Loc 0
User j
Processes & RAM
Loc n
CPU i
User k
Processes & RAM
Loc n
CPU j
CPU k
Abstract
RAM
User i
Processes
User j
Processes
Actual
User k
Processes
Loc 0
Loc n
CPU
Page space
© 2004, D. J. Foreman
3
Process Manager Responsibilities
 Define
& implement the essential characteristics
of a process and thread
■
■
Algorithms for behavior
Process state data
 Define
the address space (and thus available
content)
 Manage the resources (I/O, RAM, CPU)
 Tools to manipulate processes & threads
 Tools for scheduling the CPU (Ch 7)
 Tools for inter-thread synchronization (Ch 8,9)
 Handling deadlock (Ch 10)
 Handling protection (Chapter 14) (if time
permits)
© 2004, D. J. Foreman
4
Resources
 What
is a "resource"
Requestable blocking object or service
■ Reusable – CPU, RAM, disk space, etc
■ Non-reusable (consumable)
■
• Data within a reusable resource
 R={Rj|0<=j<=m}
Rj is one type of resource, such as RAM
 C={c >=0| R R(0<=j<m)}
■
j
■
j
cj is the # of available units of Rj
© 2004, D. J. Foreman
5
Resource Mgmt Model

{Mgr} : Rj (Mgr(Rj) gives ki<=ci units of
Rj to Pn)
 Pn may only request i units of Rr
 Pn may only request unlimited units of Rn
 Why
■
do we need the set notation?
Formalized descriptions can lead to deadlock
detection and prevention algorithms
© 2004, D. J. Foreman
6
Windows NT/2K/XP Process Mgmt
 Split
■
into 2 facilities:
NT Kernel
• Object mgmt
• Interrupt handling
• Thread scheduling
■
NT Executive
• All other Process aspects
■
See "Inside Windows 2000", 3e, Solomon &
Russinovich, Ch. 6, MS Press, 2000
© 2004, D. J. Foreman
7
The Address Space
 Boundaries
of memory access
 H/W can help (DAT) (more later)
 Multiprogramming possible without H/W!!!!
Self-relocation
■ Pre-load relocation
■ Both use true addresses FIXED at load time
■ NO paging, but MAY have swapping
■
• Windows 3.1
• IBM OS/VS1
© 2004, D. J. Foreman
8
Address Binding
 Given:
int function X(y,z)
{Int q; return ff(y,z)}
Void function M {X(3,4);}
 Where
are X, y, z and q??
 How does X get control from M?
 What happens if there is an interrupt
BETWEEN M's call to X and X starting?
© 2004, D. J. Foreman
9
Address Binding-2-fixed
1.
2.
3.
4.
5.
6.
7.
8.
Gather all files of the program
Arrange them in RAM in linear fashion
Determine runloc for the executable
Find all address constants (functions and
External data)
Find all references to those constants
Modify the references in RAM
Store as an executable file
Run at the pre-determined location in RAM
© 2004, D. J. Foreman
10
Address Binding-3-dynamic
 Perform
"fixed binding", but in step 3, use
a value of "zero"
 In step 6, mark as "relocatable"
 For step 8, before actually transferring
control, REPEAT 4-6 using the actual
runloc determined by the loader
 Same
© 2004, D. J. Foreman
for DLL members
11
Address Binding-4 DLL's
 How
does a program find a DLL it didn't
create?
 Each
DLL member has a specific name
 System has list of DLL member names
 When DLL is requested, system fetches
module and dynamically binds it to
memory, but NOT to the caller!
 System transfers control to DLL member
© 2004, D. J. Foreman
12
Address Binding - 5
 How
does the system make it look as if
each abstract machine starts at 0?
 How does the system keep user spaces
apart
 How does the system protect address
spaces
© 2004, D. J. Foreman
13
Context Switching
 Power
on, ROM reads bootstrap program
from head 0 of device
 ROM transfers control to the program
 Bootstrap program reads the loader
 Loader reads the kernel
 Kernel gets control and initializes itself
 Kernel loads User Interface
 Kernel waits for an interrupt
 Kernel starts a process, then waits again
© 2004, D. J. Foreman
14
Context Switching - 2
 Device
requests interrupt
 ROM inspects system for ability to accept
 If interrupts are masked off, exit
Future interrupts may be queued by hardware
■ Or devices may be informed to re-try
■
 If
interrupts are allowed:
set status (in RAM, control store, etc)
■ Atomically: load new IC, privileged mode,
interrupts masked off
■
 Kernel
© 2004, D. J. Foreman
processes the interrupt
15
Context Switching - 3
 The
■
actual Context Switch:
Save all user state info:
• Registers, IC, stack pointer, security codes, etc
■
Load kernel registers
• Access to control data structures
 Locate
the interrupt handler for this device
 Transfer control to handler, then:
Restore user state values
■ Atomically: set IC to user location in user
mode, interrupts allowed again
■
© 2004, D. J. Foreman
16
Questions to ponder
 Why
must certain operations be done
atomically?
 What restrictions are there during context
switching?
 What happens if the interrupt handler runs
too long?
 Why must interrupts be masked off during
interrupt handling?
© 2004, D. J. Foreman
17
What is a "Handle"?
 Application
■
requests an object
A window, a chunk of RAM, a file, etc.
 Must
give application a way to access it
 Done via a "handle"
A counter (file handles)
■ An address in user RAM (structures)
■ Always a "typed" variable
■
• Helps insure correct usage (except "C" doesn't
enforce typed usage)
© 2004, D. J. Foreman
18