CPS 346 & 444/544 Lecture notes: Processes

(manipulation)


Coverage: [UPE] §7.4 (pp. 220-225), and [USP] Chapters 1 and 3 and §4.6 (pp. 119-128)

fork exercises

  • open followed by fork; consequences?
  • fork followed by open; consequences?
  • what about the consequences of buffering? printf followed by a fork, with and without a newline
  • creating a chain of n processes
  • creating a fan of n processes

wait

  • causes the parent (caller) to block until child's status becomes available (typically after it terminates, but also when process stopped) or until the caller receives a signal
  • wait vs. waitpid (can wait for a specific process and be used to poll a process for its status without blocking)
  • r_wait
  • how can a process wait for all of its children?
  • self-study: functions (macros) for testing the return status of a child (see [USP] §3.4.1, pp. 76-77)
  • zombie process, orphans, init process

Graphical depiction of wait

(ref. [ATT] 6-41)

fork and wait exercises

  • exercise 3.10 from [USP], p. 69
  • exercise 3.18 from [USP], p. 74
  • exercise 3.20 from [USP], p. 75
  • exercise 3.21 from [USP], p. 76

exec

  • family of functions which provide support for swapping out the image of the calling process and replacing it with a new image
  • traditional fork-exec sequences
    • child swaps in the new image (with exec)
    • parents continues to execute original code
  • 6 variations differ in the way command-line arguments and the environment are passed, and in relative and absolute paths to executable
    • use execl (execl, execlp, execle) functions when you know the number of command-line arguments at compile time
    • use execv (execv, execvp, execve) functions when you will not know the number of command-line arguments until run time; use an argument array to pass command-line arguments (e.g., such as one produced with makeargv); how can the combined use of exec and makeargv cause a memory leak?
    • trick to remember which call does what
  • exec ksh (shell builtin)
  • system function: invokes a command-line in the parent shell

Graphical depiction of exec

(ref. [ATT] 6-21)

Graphical depiction of suite of exec system calls

Investigating questions

(courtesy William Kimball, CPS 445, Winter 2006)
  • why go through the overhead of copying process image if you are simply going to replace it with another image?
    • newer versions of fork (see 3.0BSD) do not copy the process image on a fork until a modification to address space is made; this is called a copy-on-write
    • does system address this?
      • investigate vfork
        • same as fork but suspends the parent until an exec or exit is called
        • does not copy the process image, shares it instead
      • system calls vfork and exec then waitpid, blocks until child terminates
  • can the l family of exec calls be used when the number of arguments are unknown until run-time? build a string representing the call to execlp and then invoke it
    • trivial in an interpreted, functional language such as Scheme
    • how about in C?

Overview of process creation and manipulation system calls


(ref. [ATT] 6-7)

Process recap

  • fork
    • called once, returns twice
    • initial value of
      • child's data is parent's data at time of fork
      • child's PC is instruction immediately following fork
    • child and parent have same
      • user id
      • group id
      • process group id
      • root directory
      • current working directory
      • signal handling settings
      • file mode creation mask
    • they differ in
      • process id
      • parent process id
    • child and parent share
      • data
      • open files
        • typically parent closes file after fork to avoid sharing file
        • though can be used as a communication mechanism
      • do parent and child share program text in main memory?
    • they do not share file descriptors; child has its own copies of parent's file descriptors
    • when is it convenient to have exact copies of parent process in memory? consider a network server process; might fork itself to handle a request
    • how is fork executed?
  • how is execlp executed?
  • UNIX init, login, and command shell processes
  • background processes
    • call setsid to prevent the process from receiving any signals as a result of a ctrl-c from a controlling terminal
    • interesting questions
      • (courtesy Matt Mize, CPS 445, Winter 2006) since parent does not wait for a background process, does the init process wait for it?
      • (courtesy Matt Mize, CPS 445, Winter 2006) does running a process in the background change the parent pid of the background process?
      • can we pass an & to the execl family of functions to run the swapped-in process in the background?

Cooperating processes

  • various processes share data
  • cooperating processes must communicate and synchronize activities
  • one classic example: consumer-producer problem
  • there are relationships between processes

Concurrency and communication

  • go hand in hand with each other
  • concurrent: one or more events which occur either simultaneously (at the same time) or so close together in time that they seems to occur at the same time; later part conflicts with the dictionary definition of concurrency (i.e., simultaneous, concomitant, and at the same time)
  • two ways to achieve concurrency in a computer system:
    • use multiple physical processors (called a multiprocessor system)
    • time-share a single CPU among multiple process (i.e., interleave the executions of the instructions of each process by allocation a very small fraction of time to each process (called the time slice) and context switching between processes when the slice expires)
  • concurrency is achieved in UNIX with the system calls fork, wait, and exec
  • processes with a common ancestor can communicate through pipes
  • processes without common ancestor can communicate through signals, queues, semaphores, monitors, shared address space, messages

Distributed computation

  • client-server model (e.g., ftp and http)
  • object-based model
    • theme: objects passing messages to each other
    • encourages code reuse
  • application (software) layers (e.g.,
    • MPI (Message Passing Interface)
    • CORBA (Common Object Request Broker Architecture)
    • RMI (Remote Method Invocation) and
    • other P2P (Peer to Peer) approaches)

References

    [ATT] UNIX System Calls and Libraries -- Part 1, Version 2.1.1, AT&T, 1990.
    [C] C Language for Experienced Programmers, Version 2.0.0, AT&T, 1988.
    [UPE] B.W. Kernighan and R. Pike. The UNIX Programming Environment. Prentice Hall, Upper Saddle River, NJ, Second edition, 1984.
    [USP] K.A. Robbins and S. Robbins. UNIX Systems Programming: Concurrency, Communication, and Threads. Prentice Hall, Upper Saddle River, NJ, Second edition, 2003
Return Home