CS 346 – Chapter 3

1. CS 346 – Chapter 3 • What is a process • Scheduling and life cycle • Creation • Termination • Interprocess communication: purpose, how to do it • Client-server: sockets, remote procedure call • Commitment • Please read through section 3.4 by Wednesday and 3.6 by Friday.

2. Process • Goal: to be able to run > 1 program concurrently • We don’t have to finish one before starting another • Concurrent doesn’t mean parallel • CPU often switches from one job to another • Process = a program that has started but hasn’t yet finished • States: • New, Ready, Running, Waiting, Terminated • What transitions exist between these states?

3. Contents • A process consists of: • Code (“text” section) • Program Counter • Data section • Run-time stack • Heap allocated memory • A process is represented in kernel by a Process Control Block, containing: • State • Program counter • Register values • Scheduling info (e.g. priority) • Memory info (e.g. bounds) • Accounting (e.g. time) • I/O info (e.g. which files open) • What is not stored here?

4. Scheduling • Typically many processes are ready, but only 1 can run at a time. • Need to choose who’s next from ready queue • Can’t stay running for too long! • At some point, process needs to be switched out temporarily back to the ready queue (Fig. 3.4) • What happens to a process ? (Fig 3.7) • New process enters ready queue. At some point it can run. • After running awhile, a few possibilities: • Time quantum expires. Go back to ready queue. • Need I/O. Go to I/O queue, do I/O, re-enter ready queue! • Interrupted. Handle interrupt, and go to ready queue. • Context switch overhead 

5. Creation • Processes can spawn other processes. • Parent / child relationship • Tree • Book shows Solaris example: In the beginning, there was sched, which spawned init (the ancestor of all user processes), the memory manager, and the file manager. • Process ID’s are unique integers (up to some max e.g. 215) • What should happen when process created? • OS policy on what resources for baby: system default, or copy parent’s capabilities, or specify at its creation • What program does child run? Same as parent, or new one? • Does parent continue to execute, or does it wait (i.e. block)?

6. How to create • Unix procedure is typical… • Parent calls fork( ) • This creates duplicate process. • fork( ) returns 0 for child; positive number for parent; negative number if error. (How could we have error?) • Next, we call exec( ) to tell child what program to run. • Do this immediately after fork • Do inside the if clause that corresponds to case that we are inside the child! • Parent can call wait( ) to go to sleep. • Not executing, not in ready queue

7. Termination • Assembly programs end with a system call to exit( ). • An int value is returned to parent’s wait( ) function. This lets parent know which child has just finished. • Or, process can be killed prematurely • Why? • Only the parent (or ancestor) can kill another process – why this restriction? • When a process dies, 2 possible policies: • OS can kill all descendants (rare) • Allow descendants to continue, but set parent of dead process to init

8. IPC Examples • Allowing concurrent access to information  • Producer / consumer is a common paradigm • Distributing work, as long as spare resources (e.g. CPU) are around • A program may need result of another program • IPC more efficient than running serially and redirecting I/O • A compiler may need result of timing analysis in order to know which optimizations to perform • Note: ease of programming is based on what OS and programming language allow

9. 2 techniques • Shared memory • 2 processes have access to an overlapping area of memory • Conceptually easier to learn, but be careful! • OS overhead only at the beginning: get kernel permission to set up shared region • Message passing • Uses system calls, with kernel as middle man – easier to code correctly • System call overhead for every message  we’d want amount of data to be small • Definitely better when processes on different machines • Often, both approaches are possible on the system

10. Shared memory • Usually forbidden to touch another process’ memory area • Each program must be written so that the shared memory request is explicit (via system call) • An overlapping “buffer” can be set up. Range of addresses. But there is no need for the buffer to be contiguous in memory with the existing processes. • Then, the buffer can be treated like an array (of char) • Making use of the buffer (p. 122) • Insert( ) function • Remove( ) function • Circular array… does the code make sense to you?

11. Shared memory (2) • What could go wrong?... How to fix? • Trying to insert into full buffer • Trying to remove from empty buffer • Sound familiar? • Also: both trying to insert. Is this a problem?

12. Message passing • Make continual use of system calls: • Send( ) • Receive( ) • Direct or indirect communication? • Direct: send (process_num, the_message) Hard coding the process we’re talking to • Indirect: send (mailbox_num, the_message) Assuming we’ve set up a “mailbox” inside the kernel • Flexibility: can have a communication link with more than 2 processes. e.g. 2 producers and 1 consumer • Design issues in case we have multiple consumers • We could forbid it • Could be first-come-first-serve

13. Synchronization • What should we do when we send/receive a message? • Block (or “wait”): • Go to sleep until counterpart acts. • If you send, sleep until received by process or mailbox. • If you receive, block until a message available. How do we know? • Don’t block • Just keep executing. If they drop the baton it’s their fault. • In case of receive( ), return null if there is no message (where do we look?) • We may need some queue of messages (set up in kernel) so we don’t lose messages!

14. Buffer messages • The message passing may be direct (to another specific process) or indirect (to a mailbox – no process explicitly stated in the call). • But either way, we don’t want to lose messages. • Zero capacity: sender blocks until recipient gets message • Bounded capacity (common choice): Sender blocks if the buffer is full. • Unbounded capacity: Assume buffer is infinite. Never block when you send.

15. Socket • Can be used as an “endpoint of communication” • Attach to a (software) port on a “host” computer connected to the Internet • 156.143.143.132:1625 means port # 1625 on the machine whose IP number is 156.143.143.132 • Port numbers < 1024 are pre-assigned for “well known” tasks. For example, port 80 is for a Web server. • With a pair of sockets, you can communicate between them. • Generally used for remote I/O

16. Implementation • Syntax depends on language. • Server • Create socket object on some local port. • Wait for client to call. Accept connection. • Set up output stream for client. • Write data to client. • Close client connection. • Go back to wait • Client • Create socket object to connect to server • Read input analogous to file input or stdin • Close connection to server

17. Remote procedure call • Useful application of inter-process communication (the message-passing version) • Systematic way to make procedure call between processes on the network • Reduce implementation details for user • Client wants to call foreign function with some parameters • Tell kernel server’s IP number and function name • 1st message: ask server which port corresponds with function • 2nd message: sending function call with “marshalled” parameters • Server daemon listens for function call request, and processes • Client receives return value • OS should ensure function call successful (once)