CS3224 Chapter 2

1
CS3224 Chapter 2

• Processes and Threads

2
Whats a process?

• Static versus dynamic view of a program
• Source code is the static view
• Processes are the dynamic view
• Aside Differences between the views is what
  leads to bugs
• A process has context
• Address space it runs in
• Bounds plus protection information
• Program counter of instruction being executed
• Register contents
• Interrupts happening, and to be fielded

3
Process states

• Running (self explanatory)
• Blocked (waiting for something)
• Typically I/O
• Possibly information from another process
• Ready (higher priority is running)

4
Whats a thread?

• A flow of execution
• A process is a heavy thread
• Includes stuff for memory management, etc.
• A thread is a lightweight process
• Shares the address space with other threads
  (including the process)
• Context is simpler
• Usually theres one process per address space,
  possibly more threads

5
Process State Table
6
Process State Table
Start
7
How Does a Process Start?

• System initialization done by system
  initializer
• Process that run continuously as services
• Typically network software, etc.
• Include things like terminal logons
• System monitors
• Fork from another process
• Background process while you continue
• Assembly line way of doing things

8
How Else?

• User starts a new process
• Types in a command
• Selects an icon from a GUI
• Batch processing new work submitted
• Similar to terminal system
• Something called an initiator waits for work
  and starts up invoked program

9
Process State Table
Start
End
10
How Does a Process End?

• Normal exit
• Does a return from the main program
• Usually includes condition code so indicate
  success
• 0 All OK
• 4 Warnings, overall execution OK
• 8 Errors, execution successful, but with errors
• 12 Severe errors, execution probably no good
• 16 Fatal error, execution definitely no good

11
Other ways to end

• Error exit
• Via exit function in C/C
• Sends back return code
• Immediate end to program, doesnt return through
  program stack
• Fatal error you probably saw this in CS1114
• Overflows, illegal storage request, etc.
• Killed by another process
• Fork process kills you (kill command in UNIX)
• Security considerations in who can do this

12
Comments

• Task start and end are strategic events
• They only happen once per process (and thread)
• They dont happen very often
• Now well look at tactical changes
• Theyll happen frequently

13
Whats the relationship between things?

• When a process starts another process, is there
  an ordering?
• Two approaches
• Yes, theres a hierarchy
• No, theyre equal
• Issue what happens if the first task ends?

14
Termination - Hierarchy

• Clear parent/child relationship
• Parent provides child with environment to get
  started
• Usually files and interrupts
• Differs between operating systems
• If child terminates, OK since parent controls
  overall environment
• Analogy to normal program execution

15
Hierarchy Termination (contd)

• What happens if parent dies?
• Real bad news since parent has the environment
• First option Kill all the children, then let the
  parent terminate can be messy
• Second option Suspend the parent until all
  children terminate, then end the parent
  cleaner, but unknown time, plus possible polluted
  environment

16
Equality - Termination

• Child gets its own environment, usually copied
  from creator
• They now run as equals
• If either terminates, the other one doesnt care
• If either gets into a runaway/hung state, the
  other cant do anything about it

17
Process State Table
Running process requests some sort of resource
thats not available at this time, or is waiting
for an event to happen. Most often this is I/O,
where we want the process to relinquish the CPU
while it waits for I/O to complete. Another
possibility is that its requesting something
thats locked for example it wants to write to
a file thats being read, and will be held to
insure the read gets consistent data
Start
End
18
Process State Table
Whatever the process was waiting for is
completed. It is now marked as ready so it can
contend for the CPU. On some operating systems,
if this is the highest priority task, it will
move directly from blocked to running (e.g.
monitors), but on most it will loop through
ready first.
Start
End
19
Process State Table
This process is the highest priority ready task.
By definition it should be made running.
Start
End
20
Process State Table
This process was running, but a higher priority
task has been moved from blocked to ready. Since
the running task is no longer the highest
priority task, it is moved to ready and the
highest priority task replaces it as the
running task. This is called preemption.
Start
End
21
Process State Table
Other transitions dont make sense
ResourceRequest
Start
End
Preemptee
Resource available, or event happens
This is highest priority task (preemptor)
22
How do we manage processes?

• Strategic versus tactical
• Strategic is deciding what work to start
• Process/thread start/activation
• Happens once every few seconds
• For logons, might refuse if we have insufficient
  resources
• For batch processes, just stop looking at the
  input spool
• Strategic issue try to mix workload if you can
  not feasible for non-batch systems

23
Management - tactical

• I have a large number of processes/threads
  running which one do I dispatch?
• Happens hundreds/thousands of times per second on
  a typical system
• What information do I need to remember so I can
  stop a task and restart it later?
• Keep this information in a Process Control Block

24
Management

• Processes and threads are frequently collectively
  called tasks
• The strategic issues are called job selection
  (may be absent on many machines)
• No batch capability
• The tactical issues are called task dispatch or
  task scheduling

25
Process Control Block

• Unique name (name or serial number)
• If name, uniqueness requirement forces one user
  per system
• Serial number is more flexible
• State (ready, blocked, running)
• Program counter (so we can restart after blocked,
  also for system calls)
• Registers
• Interrupt status
• Condition code

26
Process Control Block (contd.)

• CPU scheduling information (e.g. priority)
• Maybe other stuff depending on task management
  strategy
• Memory management information (memory keys,
  bounds registers)
• Status information (open files, etc.)
• Accounting information
• If blocked, why

27
Threads

• Sometimes we dont need all this stuff
• Creating processes has a high overhead
• What about short lived processes that dont need
  resources other than CPU
• All you need is the program counter and registers
• This is called a thread (light weight process)
• Usually a child of a process

28
More Threads

• Again, threads share the address space
• They typically dont have a Process Control Block
• They dont get interrupted because they run for
  such a short time
• This is called multithreading
• If they are interruptible, all they have is
  program counter, registers, and state

29
Single Contiguous Allocation
Operating System
User
30
PCB Strategies

• Single Contiguous Allocation Scalar
• You only have one Process Control Block
• Usually dont allow threads so you can keep
  things simple
• Minimal task dispatcher

31
Static Partitioning
Operating System
Always 3 user tasks, no more (maybe less)
User1
User2
User3
32
PCB Strategies

• Static Partitioning Carve up memory into a
  known number of processes Array
• Fixed multiprogramming level
• Threads not allowed
• Not used much any more, except on small systems
• Very efficient for task dispatch

33
Dynamic Partitioning
Multiprogramming level fluctuates widely, and
usually has a very high upper bound, if any.
Upper limit is usually limited by memory
available, CPU becoming saturated, or performance
issues
34
PCB Strategies

• Dynamic Partitioning Give each process an area
  with size it wants
• Highly varying multiprogramming level
• Unknown maximum level Linked list
• Threads are OK
• Most flexible, with the highest overhead
• Need a default size, plus the means to override
  it
• Virtual memory can fix this (more later)

35
What Happens When We Switch Processes?

• Need to save running process
• Need to start new highest priority dispatchable
  task
• These are mirror images of each other
• The overall process is called a context switch

36
Scenario

• Process A is running and requests I/O
• Process B will run while Process A is blocked
• I/O will complete, so Process A should be
  dispatched again

37
Process A Requests I/O

• Process A sets up registers so that kernel will
  know what I/O it wants typically pointers to
  control blocks (structures)
• Process A executes system call instruction

38
Kernel Wakes Up

• System call transfers to a predefined place in
  memory determined by hardware
• System call handler lives there
• Machine is automatically put in supervisor state
• System call handlers first job is to save the
  calling processs context
• Registers, interrupts, condition code, program
  counter, etc.
• System call handler looks at byte after system
  call instruction to get service code and branches

39
Second Level Handler

• Code indicated I/O, so I/O handler is activated
• Reads pointers to get what it needs to start the
  I/O, checks for validity
• If invalid, nukes Process A
• Marks Process A as blocked for I/O

40
More Second Level Handler

• Puts Process A on blocked list of processes,
  indicating its waiting for I/O
• Adds Process A to Waiting for I/O list showing
  device and process
• Starts I/O on behalf of Process A
• Branches to task dispatcher

41
Task Dispatcher

• Runs down list of Process Control Blocks, already
  in priority order
• Finds first task thats ready
• In this scenario, its Process B
• Loads Process context from Process Control Block
• Registers, interrupts, condition code, program
  counter, etc.
• Switches from supervisor to user and branches to
  Process B
• Usually some sort of hardware instruction

42
Process B Wakes Up

• Process B context restored by task dispatcher
• Process B runs
• I/O Interrupt occurs (started earlier), so we do
  another context switch

43
I/O Interrupt Handler Wakes Up

• Automatically via hardware, which saves I/O
  address in predefined location
• Saves Process B context
• Registers, interrupts, condition code, program
  counter, etc.
• Marks Process B as ready
• Reads predefined location to get I/O Address

44
I/O Interrupt Handler

• Looks in Waiting for I/O list to see what
  process is waiting for this device, finds Process
  A
• Looks to see how I/O went, sets codes in control
  block from Process A (OK, EOF, error, etc.)
• For bad error, nukes Process A
• Marks Process A as ready
• Branches to task dispatcher

45
Task Dispatcher

• Runs down list of Process Control Blocks, already
  in priority order
• Finds first task thats ready
• Finds Process A
• Loads Process context from Process Control Block
• Registers, interrupts, condition code, program
  counter, etc.
• Switches from supervisor to user and branches to
  Process A
• Usually some sort of hardware instruction

46
Cooperating Processes

• Why?
• Information sharing databases
• Need for integrity
• Computational speedup overlay I/O and
  computation in your own program
• Modularity
• Divide and conquer approach
• Convenience do large compile while editing

47
Types of modules One shot

• Typical main program
• No serious housekeeping needed
• Easy termination

48
Types of Modules Serially reusable

• Subprogram
• Have to worry about life of data between
  invocations
• Static variables vs. dynamic
• More housekeeping required
• Post-termination must be identical to pre-start

49
Types of modules recursive

• Static and dynamic view much different
• Code is more complex
• Multiple generations of storage
• LIFO storage
• Must be careful not to auger into the ground
• More complex task termination issues

50
Types of modules reentrant

• Multiple dynamic views
• Multiple generations of storage
• Multiple process control blocks
• Concern about updating variables (more about this
  in a few minutes)

51
Terminology

• Most software modules are called single thread
• Only one process (or thread) active in it at a
  time
• The alternative is called multi-thread
• AKA reentrant

52
Inter-process communication (IPC)

• How do we synchronize things?
• First alternative WAIT and POST
• System call looking at a common bit
• Second approach (more complex) Enqueue and
  Dequeue
• System call using resource names
• Typically at least two levels
• First level is type of resource
• Second level is unique name
• ENQ SYSEVENT,IPCNAME

53
IPC

• Synchronization is part of a larger issue of
  synchronization well talk more about later
• There are other issues
• How do we pass data?

54
How do we communicate things?

• Use mailboxes Send and Receive
• UNIX approach sockets
• How big can the mailbox be?
• One entry possible performance issue
• Fixed limit how big?
• Infinite what about runaways?

55
Communication Termination

• What happens if a task abnormally terminates?
• First approach Do nothing
• Easily implemented!
• Pretty dumb
• Queues ultimately fill up, possibly causing
  system hang/failure
• Many operating systems do this

56
Communication termination

• Second approach Dirty Harry/Arnold
• Kill the other end of the pipe
• See theyre connected to and kill them too
• Solves the system overload problem
• Possible collateral damage

57
Communication Termination

• Third approach
• Outbound acknowledge and trash
• Saves the sender task from an innocent death
• Can cause problems if the sender thinks something
  is happening
• Inbound close the socket
• Hopefully, will cause the receiver to terminate
  gracefully

58
How do we protect data?

• Consider this code
• i0
• i
• cout ltlt i
• For a single thread, this is fine
• What about multiple threads?

59
Protection

• Two processes, A and B
• A runs code
• Initialize to zero
• Increment i (from 0 to 1)
• Print i (1)
• B runs code
• Initialize to zero
• Increment i (from 0 to 1)
• Print I (1)
• No problem, essentially single thread

60
Protection

• i0
• i
• cout ltlt i
• Process A initializes i (0)
• Process A increments i (to 1)
• Process B reinitializes i (0)
• Process B increments i (to 1)
• Process B prints i (1)
• Process A prints i (1)
• The right answer for the wrong reasons!

Process A gets interrupted
61
Protection

• i0
• i
• cout ltlt i
• Process A initializes i (0)
• Process B reinitializes i (0)
• Process B increments i (to 1)
• Process B prints i (1)
• Process A increments i (to 1)
• Process A prints i (2)
• Bad answer!

Process A gets interrupted
62
Protection

• i0
• i
• cout ltlt i
• Process A initializes i (0)
• Process B reinitializes i (0)
• Process B increments i (to 1)
• Process A increments i (to 1)
• Process A prints i (2)
• Process B prints i (2)
• Two bad answers!

Process A gets interrupted
63
Whats Wrong?

• The initialization, increment, and print must be
  done as a group
• If theyre not, we get bad answers
• This is where the static view and dynamic view of
  a program are MUCH different
• Usually due to bad timing
• Essentially impossible to reproduce
• Timing will be different

64
How to get protection

• Statements that must run as a group are called a
  critical region
• You want to run a critical region single thread
• Cannot make any assumptions on timing or how many
  processes want to acquire the critical region
• You need to protect a critical region with a lock
  of some kind

65
Locks and Critical Regions

• Setting of lock ALWAYS immediately precedes the
  critical region
• Clearing of lock ALWAYS immediately follows the
  critical region

66
Ways to communicate

• First approach spin lock
• x0 // initial condition
• while(x!0)
• x1
• critical region
• x0

67
Spin Lock Strategy

• while(x!0)
• x1
• critical region
• x0
• Initially while fails, and process sets the
  lock and enters the critical region
• If process is in the critical region and another
  arrives, it loops on the while
• As first leaves, causes while to fail, next
  enters (and sets the lock again)

68
Doesnt work!

• Why not?
• Interruption between while and assignment
• while(x!0)
• x1
• Need test and set to be indivisible, called an
  atomic operation
• Many machines have test and set instruction or
  swap instruction
• Individual instructions are not divisible,
  therefore are atomic

First process interrupted here
69
Atomic spin lock Test and Set

• Test and set sets the data and returns via the
  condition code what the data was
• Relies on instruction execution being atomic
• X0 // at the beginning of time
• L TS LOCK test and set the lock
• BNZ L
• critical region
• MOV X00,LOCK reset the lock

70
Atomic Spin Lock - Swap

• Swap swaps two words
• Sets one word
• Second word tells you what the value was
• Second word is used to set the first
• MOV X00,LOCK1
• MOV X01,LOCK2
• L SWAP LOCK1,LOCK2
• CMP LOCK2,X00
• BNE L
• critical region
• MOV LOCK1,X00

71
Spin locks

• Whats good about spin locks?
• Extremely efficient
• Dont need system services, so operating system
  can use them
• Whats bad about spin locks?
• Burn CPU time
• Used for tactical locks short lived
• Must be used in kernel
• One reason why multiprocessing doesnt give you
  full power
• 65MP was an extreme example
• .9 CPU Equivalent, with 2 CPUs symmetric tightly
  coupled!

72
Spin Lock Variation - Alternation

• Sometimes you want to guarantee that two tasks
  alternate entering a critical region
• turn0 // at the beginning of time
• Strategy Loop if the other task has the lock,
  enter the critical region, set the lock so the
  other task runs and this one spins

73
Alternative Wait Locks

• Done via system call
• Means it cant be used by kernel
• Wait lock handler must be single thread
• Acts as a central point of control
• Uses spin lock to make critical region within
  itself
• Wait locks can be simple to complex

74
Simple wait lock - mutex

• Short for mutually exclusive
• System call to set lock if its set already,
  you are blocked, otherwise you set it
• System call to free lock check to see if
  anybody is blocked, and make highest priority
  dispatchable task waiting for the lock ready

75
Mutex locks

• Have a number of names on various operating
  systems
• WAIT/POST
• ENQUEUE/DEQUEUE
• Easy to implement
• Widely used

76
More sophisticated wait locks

• Look at a shared thing
• We can all read it at the same time
• Only one of us can write it
• And the readers have to wait
• Need a better mutex
• Use two operand lock lock name plus access
• Access is shared or exclusive

77
Shared locks

• For shared acquisition
• If locked shared, we can join in
• If locked exclusive, we are blocked
• For exclusive acquisition
• If locked in any way, we wait
• Issue
• Who gets preference on blocked tasks

78
Shared locks

• One approach, called strong readers
• Task wants shared access (AKA reader) it gets it
  if lock available or already shared
• Exclusive access (AKA writer) waits
• Leads to possibility of starvation
• As long as readers keep arriving, writer can
  never get in
• Keeps the maximum number of tasks busy

79
Shared locks

• Alternative approach strong writer
• When writer task arrives and lock is not
  available, nobody new allowed in
• Writer will get it as quickly as possible
• Readers will wait, even though maybe they could
  run to completion without impact to writer

80
A better way

• Mutex locks are binary
• Wed like a more general form
• Invented by Djikstra
• Called semaphores, after train signals
• Two operations, called P and V
• Also called Wait and Signal
• Tanenbaum calls them Down and Up
• DONT UNDERESTIMATE THE IMPORTANCE OF SEMAPHORES!

81
Semaphore operations

• s gets initial value of resources available
• Request resource
• P(s) ss-1
• if(slt0) then mark task blocked (sleep)
• Release resource
• V(s) ss1
• if(slt0) wake up highest task

82
Implementation Issues

• Done via system calls
• Semaphore management needs to be single thread
• Need table of semaphore names and values
• Need list of process IDs and semaphores they are
  waiting for
• Also put semaphore name in PCB for cross check if
  necessary

83
Who do we wake up?

• When V operation done, who gets unblocked?
• FIFO (Fair)
• Dispatch Priority (best performance)

84
Semaphores Simplified and Extended

• Note that if initial value s1, we have mutex
• This is why nobody uses mutex as shown in the
  book
• As described, P and V are not packaged together
• What happens if P and V are called simultaneously
  by two different tasks?

85
Semaphores Expanded

• Suppose we make the semaphore into an object,
  make P and V member functions
• Semaphore value itself is private data
• Might need function to see value
• Add way to serialize (single thread) the
  operations
• System call is a start, but not good enough
• Suppose calls are handled on different CPUs in a
  multiprocessing world

86
Approaches

• First approach Let system calls only be handled
  by one CPU in the kernel
• This is called CPU affinity
• In addition, make lock handler non-interruptible
• This gives us single thread on semaphore updates
• How about an alternative

87
Monitors

• Have semaphore protect itself
• Conceptually wrap P and V with a shell that only
  allows one process in at a time
• If second process wants to update while one is
  active, suspend it
• This is called a monitor
• How do we implement?
• Use spin locks on P and V with same lock variable
• Use mutex as a primitive operation

88
Monitors Explained

• Note that this is a second definition of the word
  monitor
• The first was a second generation operating
  system
• This definition is a derivation of the first
• Second generation operating systems provided
  minor synchronization services

89
Semaphore Applications

• Semaphores can be used in an extremely wide
  variety of applications
• Usually come down to two basic types of problems
• Synchronization
• Producer/consumer
• Well show some examples of each

90
Example Dining philosophers
Thinking (sleeping) philosopher (with bad hair)
Fork
91
The Problem

• Philosophers either eat or think (i.e. sleep)
• To eat, they need two forks
• They share forks
• (ignore hygiene issues)

92
Philosophers First Solution

• Each philosopher picks up their left fork, then
  their right
• Will work ALMOST all the time
• Not good enough
• What happens if everybody wakes up at once?
• Each grabs their left, nobody can grab their
  right
• This is called a deadlock
• Will NEVER get better they all wait

93
Whats a deadlock?

• More later, but for now
• Its a situation that can NEVER get better
• Everybody will wait FOREVER
• Not the same as starvation
• With starvation, things will happen eventually
• Maybe not for a very long time

94
Philosophers Second Solution

• After you get your left fork, and you cant get
  the right fork, put your left fork down
• Better, but still not good enough
• Picture everybody picking up their left fork at
  EXACTLY the same time
• Leads to military-style placing of forks
• Up/Down/Up/Down/Up/Down

95
Philosophers Third Solution

• Only allow one philosopher to eat at a time
• Obviously never deadlocks
• Can avoid starvation
• Terrible performance
• Great dieting technique!

96
Philosophers Fourth Solution

• Use array of semaphores representing the forks
• Number the philosophers starting from zero
• Even numbered philosophers pick up left fork
  first, then right
• Odd numbered philosophers pick up right fork,
  then left
• Avoids deadlock, possibility of starvation
• The best solution

97
Example Dining philosophers
1
0
0
1
4
2
3
4
2
3
98
Algorithm

• For N philosophers
• For even philosopher i
• P(forki) P(forki-1mod N)
• Eat
• V(forkiV(forki-1mod N) go to top
• For odd philosopher i
• P(forki-1mod N), P(forki)
• Eat
• V(forki-1mod N) V(forki) go to top

99
Observations

• Semaphore algorithms frequently shown in
  pseudocode
• One algorithm per entity
• Algorithm usually (but not always) loops
• Algorithms are running in parallel with each
  other
• Usually algorithm is short
• CANNOT BE SHOWN IN NORMAL PROCEDURAL CODE!

100
Sleeping Barber Problem

• One barber
• Limited number of chairs
• Barber sleeps if no customers
• Customer leaves if all chairs full

101
Solution Two Semaphores

• Assume barber shop starts empty
• One semaphore for chairs, initial value number of
  chairs
• One semaphore for customers, initial value zero

102
Barber

• P(customer) // wait for customer
• // Customer ready for haircut
• V(chair) // customer frees up chair
• Cut hair
• Go back to top

103
Customer

• If(chairs0)leave
• P(chair) // guaranteed to work
• V(customer) // possibly wake up barber
• Go to top

104
Observations

• Sum of customer and chairs always equals number
  of chairs, unless barber is sleeping
• Good way to check that we have algorithm right
• Can be easily extended to any number of barbers
• This is why semaphores are popular
• Elegant, yet very powerful

105
Interlocking

• Another key concept When moving something, make
  sure nobody jumps the gun
• Barber waits for customer
• Dont mark a chair as available until youre sure
  its empty

106
Interlocking Details

• When you move something, theres a transmitter
  and a receiver
• Receiver has to wait for data, and acknowledge it
  after its received
• Transmitter puts the data where it can be seen,
  then declares it available, then waits for
  acknowledgement
• If we dont do this, we can have an overrun or an
  underrun

107
Error Conditions

• Transmitter makes data available, doesnt wait
  for acknowledgement, and sends more data before
  receiver is ready (overrun)
• Receiver takes data, doesnt wait for
  notification that more data is ready, and takes
  incomplete data (underrrun)
• Overruns are more common

108
How to avoid errors

• Transmitter code
• Make data available
• V(data_available)
• P(data_acknowledge)
• Go to top
• Receiver code
• P(data_available) // note symmetry
• Take data
• V(data_acknowledge) // note symmetry
• Goto top

109
Interlock

• The preceding is called an interlock, also known
  as a handshake
• It is one of the most common algorithms in
  operating systems
• Mandatory to insure that data is not compromised
• The prime directive Maintain integrity, dont
  mess up data

110
Producer-Consumer
Welcome to Burgers R Us
1 cook
1 clerk
10 slots
1 burger in slot
111
Producer Consumer

• Cook is the producer, making burgers
• Slots are a limited size buffer
• Clerk is the consumer

112
Cook - Producer

• When burger is ready, cook attempts to acquire
  slot
• If no slot available, cook sleeps (and burger
  becomes VERY well done)
• When slot available, cook puts burger in slot
• Process begins again

113
Clerk - Consumer

• Clerk waits for customer
• When customer arrives, clerk attempts to acquire
  burger
• If no burger, clerk sleeps (and customer gets
  hungry)
• When burger available, clerk takes it and gives
  to customer, making an available slot

114
Overview

• We have two cooperating processes that need to
  coordinate
• Cook sleeps if no slots, and wakes up clerk if
  shes waiting for a burger
• Clerk sleeps if no slots, and wakes up cook if
  hes waiting for a slot
• Elegant solution required

115
Initial conditions

• At store opening, all the slots should be
  available, with no burgers
• Anything else will invite a visit from the Board
  of Health
• Need two semaphores
• slots10
• burgers0

116
Cook Algorithm

• // cook burger
• P(slot) // attempt to get slot, sleep if none
• // throw burger into bin
• V(burger) // announce available
• go to top

117
Clerk Algorithm

• // customer arrives
• P(burger)
• // take burger from bin, making slot
• V(slot)
• go to top

118
Observations

• Note symmetry of algorithms
• Note that for normal conditions, both semaphores
  are positive and their sum equals the initial
  number of slots (good check)
• When somebodys sleeping, semaphore indicates how
  many

119
Extension

• What do we have to do to allow for multiple
  clerks and cooks?
• With traditional software (e.g. mutex), a total
  rewrite
• Probably arrays of mutex variables
• Potential mess hard to debug
• What about semaphores?

120
Extension

• With semaphores, what needs to be done?
• NOTHING!
• They work fine as is!
• This is why semaphores are powerful

121
One Shot Assembly Line

• Two stations called A1 and A2 make something and
  send it to B
• B waits for both halves and makes an output it
  sends to C

A1
B
C
A2
122
Design Points

• A1 and A2 just start up
• B has to wait for A1 and A2
• C has to wait for B
• Easiest way to do this is to use semaphores that
  represent the originator

123
Semaphore Code

• A1
• // Assemble
• V(A1)
• A2
• // Assemble
• V(A2)

• B
• P(A1)
• P(A2)
• // Assemble
• V(B)
• C
• P(B)
• // product is complete

124
Extension

• Now lets make it a real assembly line, where we
  make many assemblies
• We now need an interlock, or handshake, between
  the stages

125
Design Points

• A1 and A2 both have to wait for an acknowledge
  from B before proceeding
• We dont care what the order of acknowledge is
• B has to wait for an acknowledge from C before
  proceeding
• As before, use originator name for semaphore
• Use acknowledge name for semaphore

126
A Stage

• A1
• // Assemble
• V(A1)
• // wait for ack
• P(B)
• go to top

• A2
• // Assemble
• V(A2)
• // wait for ack
• P(B)
• go to top

127
B and C Stages

• B
• P(A1)
• P(A2)
• // now we have both
• // halves, so go
• V(B) // for A1 or A2
• V(B) // for the other
• // assemble
• V(B) // for C
• P(C)
• Go to top

• C
• P(B)
• // Take assembly
• V(C)
• // Finish product
• go to top

128
Assembly Line

• DOESNT WORK!
• Why not?
• Look at B semaphore usage
• You cant target a semaphore
• You might set off C prematurely
• Repair
• For P semaphores, show intended recipient

129
A Stage

• A1
• // Assemble
• V(A1)
• // wait for ack
• P(BA)
• go to top

• A2
• // Assemble
• V(A2)
• // wait for ack
• P(BA)
• go to top

130
B and C Stages

• B
• P(A1)
• P(A2)
• // now we have both
• // halves, so go
• V(BA) // for A1 or A2
• V(BA) // for the other
• // assemble
• V(BC) // for C
• P(C)
• Go to top

• C
• P(BC)
• // Take assembly
• V(C)
• // Finish product
• go to top

131
Assembly Line

• Closer, but still might not work
• Why not?
• Look at BA semaphore usage
• A1 might be much faster than A2, and make two
  things (and field both P(BA) operations, and A2
  doesnt do anything
• Repair
• Never assuming timing, e.g. that A1 and A2 are
  about equally fast
• Dont use a single BA semaphore, use one for each

132
A Stage

• A1
• // Assemble
• V(A1)
• // wait for ack
• P(BA1)
• go to top

• A2
• // Assemble
• V(A2)
• // wait for ack
• P(BA2)
• go to top

133
B and C Stages

• B
• P(A1)
• P(A2)
• // now we have both
• // halves, so go
• V(BA1)
• V(BA2)
• // assemble
• V(BC) // for C
• P(C)
• Go to top

• C
• P(BC)
• // Take assembly
• V(C)
• // Finish product
• go to top

134
Assembly Finished

• Now we finally have a totally complete solution
• No directed semaphores
• No reliance on special timing

135
Summary

• Semaphores are wait locks used for coordination
• The are used by processes/threads running in
  parallel
• They are used to synchronize/coordinate processes
• The simplest semaphore has an initial value of
  one, and is called a mutex

136
Semaphore Summary (contd)

• Semaphores have other uses too
• Larger initial values allow more parallelism
• If semaphore is positive, number of available
  resources of type represented by the semaphore
• If negative, the number of blocked processes
  waiting for the semaphore
• Semaphore usually has name with mnemonic value

137
Semaphore Summary (contd)

• P operation, also known as wait, attempts to
  acquire resource represented by semaphore
• Semaphore decremented by one
• If it goes (more) negative, process goes blocked
  waiting for semaphore
• V operation, also known as signal, releases
  resource represented by semaphore
• Semaphore is incremented by one
• If updated value is nonpositive (lt0), wake a
  process up

138
Semaphore Pitfalls

• When multiple processes are waiting on a
  semaphore via a P (wait) operation, when a V
  (signal) happens, the process marked ready is
  chosen in a nondeterministic way
• You cant steer a V operation to unblock a
  specific process
• However, you can use multiple semaphores
• And complicate your program logic

139
Observations

• Multiple processes can use P and V operations on
  the same semaphore
• Ultimate premise of the semaphore is that the P
  and V operations will work on a single thread
  basis
• Algorithms are always written using pseudocode to
  represent the algorithm

140
Another ProblemThe Cigarette Smokers

• Four people are sitting around a table
• Ingredients needed to make a cigarette are
  tobacco, paper, and matches
• Three of the four people each have an ingredient
• The fourth is the dealer
• Dealer places two different ingredients on the
  table

141
Problem Statement (continued)

• Dealer wakes up proper smoker
• Smoker makes a cigarette and smokes it
• Smoker wakes up the dealer
• Process repeats

142
First Solution

• Smoker1 // has matches
• P(Paper)
• P(Tobacco)
• // if we get here he wins take ingredients
• // smoke
• V(Dealer)

143
First Solution

• Smoker2 // has paper
• P(Matches)
• P(Tobacco)
• // if we get here he wins take ingredients
• // smoke
• V(Dealer)

144
First Solution

• Smoker3 // has tobacco
• P(Paper)
• P(Matches)
• // if we get here he wins take ingredients
• // smoke
• V(Dealer)

145
First Solution

• Dealer
• P(Dealer)
• // spin wheel, get random number
• if(numberlt1/3)V(Paper)V(Tobacco)
• else if(numberlt2/3)V(Matches)V(Tobacco)
• else V(Paper)V(Matches)
• go to top

146
Initial Conditions

• Wake up dealer
• Show nothing on table
• Dealer1
• PaperMatchesTobacco0
• Now start running Dealer takes off immediately

147
Whats Wrong?

• V operations represent ingredients
• Two different smokers might each have one P
  operation work, and still wait for the other
• In fact, its likely
• System becomes deadlocked!
• Need different logic

148
The Next Attempt

• Instead of ingredients, have the semaphores
  represent who to wake up

149
Algorithms

• Dealer
• P(Dealer)
• // spin wheel, get random number
• if(numberlt1/3)V(Smoker1)
• else if(numberlt2/3)V(Smoker2)
• else V(Smoker3)
• go to top

150
Smoker Algorithms

• Smokeri
• P(Smokeri)
• // Pick up ingredients
• // Smoke
• V(Dealer)

151
Initialization

• Wake up the dealer, make the smokers sleep
• Dealer1
• Smoker1Smoker2Smoker30
• Start running Dealer takes off like before

152
CPU Scheduling

• Weve talked about cooperating tasks
• How does the big boss work
• The big boss is called the task dispatcher
• We have a contention environment
• One (maybe few) CPU
• Lots and lots of tasks

153
Goals/Policies

• CPU Utilization get your moneys worth
• Throughput maximize work
• Turnaround time
• Related, but not identical to throughput
• Waiting time political
• Response time
• Real time constraints
• Always give interactive over batch

154
What is Turnaround Time?

• Elapsed time from when work is submitted to when
  it is completed
• For batch processing, the clock starts with the
  time the work is submiited
• Includes time waiting on the input spool
• Includes time actually being served by the CPU,
  including running, blocked, and ready

155
Turnaround Time Time Sharing and Interactive

• For Time Sharing and Interactive, time from when
  command is entered to when it completes
  processing
• Includes time on input queue
• Includes time running, blocked, ready
• For Time Sharing, is usually split into classes
  of transactions
• Trivial (dir or ls)
• Normal
• Everything Else

156
Turnaround Time Real Time

• For real time, from time an event happens to when
  it is done being processed
• Hard real time is very unforgiving, must meet it
• For soft real time, usually slack left in time
  budget for each event type

157
Whats Throughput?

• A measure of work thats been done
• For batch processing, the number of batch jobs
  processed per unit time
• Unit time is usually measured in hours or days,
  i.e. We process 2000 jobs/hour
• For time sharing, its usually transactions per
  hour
• Frequently by type
• For interactive, transactions per second

158
Example

• We have three jobs, all CPU bound, that take 1
  second CPU (call them A, B, C)
• We have one job that takes 10 seconds CPU (call
  it D)
• All arrive at t0
• The sum is 13 seconds of CPU, so no matter what
  we do, well run the total of four jobs in 13
  seconds
• This gives a throughput of 4/13 jobs/sec

159
Turnaround Example 1

• Now try different strategies
• Run a small, then part of big, then a small, then
  part of big, etc.

A
D
B
D
C
D

D
0
1
2
3
4
5
6
13
D Ends
A Ends
B Ends
C Ends
160
Turnaround Example 1

• Turnaround A1, B3, C5, D13
• Average turnaround
• (13513)/4 22/4 5.5 seconds

161
Turnaround Example 2

• Now try different strategies
• Run a small, then part of big, then a small, then
  part of big, etc.

A
B
C
D
D
D

D
0
1
2
3
4
5
6
13
D Ends
A Ends
B Ends
C Ends
162
Turnaround Example 2

• Turnaround A1, B2, C3, D13
• Average turnaround
• (12313)/4 19/4 4.75 seconds
• Note how the total time to run the stream is the
  same, but the throughput changed

163
Two Step Process The 1st Half

• Strategic View Job Scheduling
• Assumes batch processing environment
• Can be used for T/S if you know ahead of time
  nature of command
• dir and ed are known to be trivial
• In any case, you need a queue of work to be done
• Decisions usually made on second by second basis
  almost forever

164
Job Scheduling Algorithms

• First Come First Served (FCFS)
• Also known as First In First Out (FIFO)
• Fair
• Not optimal by any measure
• Shortest Job (Trivial transaction) First
• Throughput and Turnaround driven
• Try to make mixed load
• Lots of I/O plus some CPU hogs - utilization

165
Two Step Process The 2nd Half

• Tactical view task dispatch
• Every operating system has this
• Decisions made on millisecond or microsecond
  basis
• Tradeoffs
• We want to give as many as we can a shot at the
  CPU to keep them happy
• Task switch carries overhead

166
Task Dispatch Data Structures

• Single Contiguous Allocation Scalar
• Static Partitioning Arrays
• Dynamic Partitioning Linked lists

167
Task Dispatch

• How do we choose
• First, were coming off an interrupt
• Have PCB chain in priority order
• Run down chain until you find a ready task
• Dispatch it
• Corollary If tight multiprocessing, mark it
  running
• Avoids another CPU picking up the same task

168
Task Dispatch

• Tight multiprocessing still look for first
  ready task
• Skip blocked and running
• New task gets default priority, typically in the
  middle
• Priority moves up and down once we get a profile
  on it

169
Task Switching

• Preemptive
• Most widely used
• Best overall management
• Tasks will be interrupted while running
• Need to save context
• More complexity and overhead
• Can mess up performance/response time

170
Task Switching

• Non-preemptive
• Running task has to voluntarily let go
• Simpler task management
• Implies less overhead
• Tasks can guarantee performance
• Probably needed for real time
• Runaway tasks can eat the machine alive
• Typically used on small machines

171
Task Switching

• Can Use Hybrid of preemptive and non-preemptive
• Defined in Operating System Tables
• Dont want users to declare themselves
• Some tasks declared to be non-preemptive
• Time critical applications
• Typically highest dispatch priority
• Typically short running

172
Task Scheduling Algorithms

• First In First Out (FIFO), also known as First
  Come First Served (FCFS)
• Give CPU in order of when they became ready
• Typically non-preemptive strategy
• Good Simple, Fair
• Bad No optimization, CPU hog mess

173
FIFO/FCFS
New ready tasks
Blocked(will become ready)
174
Task Scheduling algorithms

• Shortest Time Remaining First
• Future-based algorithm
• Relies on initial CPU estimate
• Subtract whats used with each block
• Kill them if they lie
• Sort PCBs in order to remaining time, give to
  task with least time left
• Can be unstable rarely used

175
Shortest Time First
New ready tasks
Longest
Shortest
Blocked(will become new ready task)
Queue is sorted by shortest time remainingNew
ready tasks get inserted
176
Round Robin Algorithm

• The first real algorithm
• FIFO with a time limit, called a time quantum
• Task uses quantum or goes blocked
• If quantum used, preempt
• Uses ring of PCBs
• Good No starvation, Fair
• Bad Hogs can affect response time

177
Round Robin
1 time quantum, in order
New ready tasks
Blocked(will become new ready task)
Task used entire time quantum
178
Multilevel Queuing Algorithm

• Round Robin with punishment
• When task becomes ready, goes to top level, gets
  time quantum
• If goes to blocked, OK and we start again
• If not, moves to lower level with bigger time
  quantum
• ANY task at higher level preempts lower level
  (usually)

179
Multilevel Queuing
New tasks 1 time quantum
Blocked
Heavy tasks 2 quantums
Blocked
Hogs 4 quantums
Blocked
Hog round robin
180
Multilevel Queuing (contd)

• Good Hogs get punished
• Meets response time expectations
• Fast things run really fast
• Justice
• Bad Complex queue management
• Not surprisingly, used on larger machines
• Need the management, and have the resources

181
Dynamic Dispatch

• Add field to PCB time used
• Set an alarm clock typically sub second
• Zero out PCB time used fields
• When task is dispatched, add time used to PCB
  field
• When alarm clock goes off, sort by time used
• Do it again

182
Dynamic Dispatch
Note Assume alarm value of 1 second
183
Dynamic Dispatch

• Good Self tuning
• Fast identification of CPU hogs
• Reformed hogs can get forgiveness
• Bad Multiple CPU hogs can cause anomalies
• One hog gets dispatched and eats all the time
• Other hog gets no time, becomes highest priority
  task
• Reverse roles next time around

184
Dynamic Dispatch
Note Assume alarm value of 1 second
Hog
Hog
0
185
Mean Time to Wait

• Also known as mean time to blocked
• Add multiple CPU time fields to PCB
• When task is dispatched, keep track of how much
  CPU it used until blocked
• Sort PCBS by time used fields, using weighting
  factors (older less weighted)
• Good Self tuning, and we remember CPU hogs
• Bad Forgiveness can take a long time

186
Mean Time to Wait
Hog
Hog
Light
187
Overall Strategy

• Hard real time highest human rated
• Soft real time next time critical
• Interactive next most people affected by a
  shared system
• Time sharing next
• Batch processing last
• Designed to soak up whatever CPU is left

188
Performance Analysis

• How do we know which strategy works best?
• Need to simulate
• Make an imaginary clock
• Simulate moment by moment
• Extremely expensive and slow
• Extremely high level of detail
• Lots of data that needs to be analyzed

189
Modeling

• An alternative make simplifying assumptions
• Gives good enough results
• Well show one possibility
• Preemptive static multiprocessing
• Can be easily generalized to other environments
• Not perfect, but good enough

190
Initial Assumptions

• Job/Process has uniform characteristics
• No inter-process communication
• Jobs have known profile CPU time required, CPU
  intensity
• Reasonable, use probability distributions
• All work available at t0 (easily relaxed)

191
Single Process

• For example, assume Process A
• 50 CPU busy
• Needs 1 second of CPU time
• Each second of elapsed time, Process A will burn
  .5 seconds of CPU
• Other .5 second CPU is idle
• Therefore, will complete in 2 seconds

192
Another Process

• Process B
• 20 CPU busy (i.e. more I/O bound)
• Also needs 1 second of CPU
• For each second of elapsed time, burns .2 seconds
  of CPU
• Other .8 second CPU is idle
• Will complete in 5 seconds

193
Contention

• Put both processes in same machine
• Multiprogramming/multitasking
• Top priority process will get CPU when it wants
  it, therefore no impact
• Lower priority process gets whats left
• Therefore runs slower
• Examine the two alternatives A is higher or B is
  higher

194
Process A Higher Priority

• Each second, Process A burns .5 seconds
• .5 seconds left for Process B
• Process B burns 20 of the .5 seconds left, or .1
  seconds
• Process A runs for 2 seconds, like before
• At 2 seconds, Process B has burned .2 seconds,
  has .8 to go
• At 2 seconds Process B is only thing running

195
Process A Higher Priority

• Process B now burns .2 seconds CPU per second
  elapsed time
• Terminates 4 seconds later
• Total time for Process B is 6 seconds

196
Process A Higher Priority

• Statistics
• CPU Busy
• 0-2 seconds 60
• 2-6 seconds 20
• Average Turnaround (26)/24 seconds
• Average Throughput 2 jobs in 6 seconds
• .3333 jobs/second

197
Process B Higher Priority

• Each second Process B burns .2 seconds
• Process B runs 5 seconds
• Initially Process A burns 50 of .8 seconds, or
  .4 seconds
• Process A runs 2.5 seconds
• Higher priority Process B runs longer than
  Process A and is unaffected by it
• An easier situation

198
Process B Higher Priority

• Statistics
• CPU busy
• 0-2.5 seconds 60 busy
• 2.5-5 seconds 20 busy
• Average turnaround (2.55)/23.75 seconds
• Average throughput 2 jobs in 5 seconds
• .4 jobs/second

199
Extensions

• Same algorithm can be used for lots of tasks
• Start with highest priority task, calculate burn
  and whats left
• Move on to lower priority tasks
• Go until 100 CPU (CPU-bound task)
• Go until all tasks accounted for
• Be very careful about tasks terminating
• Changes environment, recalculate

200
Extensions

• Tasks may terminate within an interval
• Need to subdivide interval and prorate effects
• Allow work to arrive after t0
• No problem, just more complicated
• Use same approach as for termination
• Overall, easily implemented in software
• Just do very careful bookkeeping
• Fast, easy model