1 / 17

CS 346 – Chapter 3

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. Process.

haydeev
Download Presentation

CS 346 – Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related