1 / 42

Programming with Processes and Threads in Unix

Programming with Processes and Threads in Unix. References. References: Unix Internals, The New Frontiers, Uresh Vahalia Unix System V Release 4, Kenneth Rosen, Richard Rosinski, James Farber. A Little Unix History. Late 1960’s Bell Labs, GE, MIT:

catori
Download Presentation

Programming with Processes and Threads in Unix

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. Programming with Processes and Threads in Unix

  2. References • References: • Unix Internals, The New Frontiers, Uresh Vahalia • Unix System V Release 4, Kenneth Rosen, Richard Rosinski, James Farber

  3. A Little Unix History • Late 1960’s Bell Labs, GE, MIT: tried to develop multiuser O.S., called Multics • Early 70’s: first Unix system including file system and shell. • 1973 First version of Unix in C: Made it first O.S. written in a high-level language. Significant! Increased its portability.

  4. A Little Unix History • Several attributes of Unix contributed to its growth in popularity: • Portability due to high level language • Simplicity of the earliest kernel code • Simple licensing (ATT couldn’t market due to antitrust litigation)

  5. A Little Unix History • Several attributes limited Unix: • Simplicity in the code did not remain • Free licensing led to lots of unstructured changes • Traditional kernel not easily extended • Ease of use, or lack thereof • Need for simpler interfaces for app. development

  6. A Little Unix History • Two Major Variants: • BSD (Berkeley Software Distribution) • Funded by DARPA, made major technical contributions: • Integration of TCP/IP • System V (ATT gets back in the game) • Responsible for: • IPC (Interprocess Communication)

  7. Mini Unix Primer • Some generally useful commands: • ls list contents of current directory, -l, -lA • pwd print working directory • cd change directory • mkdir make a new directory, rmdir remove it • cp copy a file, mv move it, rm delete it • lpr print • Other sources: • http://www.cs.msstate.edu/~cs2314/fall01 • Go to “Helpful Things” • “Unix Pocket Reference”

  8. Mini Unix Primer • Editing and Compiling • Editors: joe, pico, vi, emacs • Compiling: gcc, g++, cc, CC • See handout in class • Other useful commands • man (man, i.e., manual pages) • Can be invoked for any Unix command • Ex.: man cp

  9. Mini Unix Primer File Ownership /Permissions • UID every user gets one • GID every user assigned to a group • SuperUser- sys admin, UID 0, GID 1 • File has permissions for user, group, and “other” • rwx r-x r-- … myfile • Useful command: • chmod ugo+rwx myfile

  10. Mini Unix Primer Processes • Process 0- system process created when Unix boots. • Process 1 -init process- all other processes are spawned from this • Sets up system in single or multi-user mode • Spawns log-in shells for users • Exists as long as system runs, ancestor of all other processes on system • Other PID’s start at 2, assigned sequentially to run to max, then go back and look for those skipped

  11. Mini Unix Primer Processes Useful commands: ps (process status) no options gives info for your terminal PID TTY TIME COMMAND -f full option adds PPID, StartTime, and Index -l long option adds process state, O,S, R, I, Z, T, X kill PID kills a process -9 kills a login shell 0 kills all processes created during a login shell

  12. Mini Unix Primer Processes Other useful commands: bg (or &) run process in background fg bring process to foreground jobs list all running jobs

  13. Mini Unix Primer • Log-in Shells • What is a shell? Command-line interpreter • Versions: sh, csh, ksh, bash • For version history, see UnixHelpDesk url • FYI: disney runs bash • Important to remember: your login-shell is the parent of all processes created during your login session

  14. Process and the Kernel • Kernel • set of core functions • initializes system, creates initial processes, which create others, remains in memory until system shuts down • Manages process and services to them • Handles hardware interrupts • Controls memory management and scheduling

  15. Process and Kernel: Kernel Mode vs. User mode • Kernel mode: more privileged mode • Protects memory address space from user-mode access • Certain privileged machine instructions, e.g. memory management register manip., can only execute in kernel mode • Prevents user process from accidentally or maliciously corrupting other processes or the kernel- damage is localized and only affects specific user process

  16. Process and Kernel • Kernel can directly access address space of process, but… • System (kernel) space is protected from user-mode access. • Process cannot directly access the kernel, must instead use.. • system call interface

  17. System Call Interface • When process makes a system call, it executes special sequence of instructions to put system in kernel mode (mode switch) and transfer control to kernel. Kernel handles operation for process. • After system call completes, kernel executes another set of instructions that returns the system to user mode (mode switch) and transfers control back to process.

  18. Process Creation • fork • The fork system call creates a new process. • Calling process is parent • New process is child • Child is almost exact clone of parent

  19. fork • To differentiate, fork returns different values to parent and child: • 0 to child • child’s PID to parent • Both parent and child execute same program, have identical data and stack regions, and resume execution at instruction immediately following call to fork.

  20. fork • fork system call must do many things, including: 1. Allocate new PID and PCB for child 2. Initialize PCB by copying some data from parent, and initializing child-specific: a. Copy process state, scheduling, mem. mgmt. and hardware context from parent b. Set PID, PPID specific to child, CPU usage to zero, etc. 3. Get references to shared resources inherited by the child, i.e., open files and current working directory 4. Make child runnable and put it on scheduler queue 5. Have child return from fork with value of zero 6. Return PID of child to parent

  21. exec • exec overlays a new program on the existing process. • Often, child process will call exec shortly after returning from fork, and thus begin executing a new program. • Thus, child does not return to old program unless exec fails. • On successful completion of exec, child’s address space is replaced with that of new program and returns to user mode executing first instruction of new program

  22. Example of fork and exec if ((result= fork()) = = 0) { /* child code */ … if (exec (“new_program”), …) < 0) perror(“exec failed”); exit(1); } else if (result < 0) { perror(“fork”); } /* parent continues here */

  23. Why use fork and exec? • Why not make them one call since child often discards parent to do exec? • Because! • Modularity, Flexibility • Client-server apps may want clones • Process may want to invoke new program without creating a new process • Child may want to do things between fork and exec, I.e., change uid or process group, close files inherited from the parent, but not needed, etc.

  24. fork optimization • Older Unix systems made an actual copy of address space <– wasteful • Two methods to address this: • SV uses copy-on-write approach (Assumes VM) Child gets copy of address-translation maps, but shares memory pages. Only a page that is referenced by parent or child gets copied (until child calls exec.) • BSD uses vfork Does no copying. Parent loans its address space to child and blocks until child returns it. Child executes using parent’s address space until it calls exec or exit, wherein kernel returns address space to parent and unblocks it. Note: Dangerous!

  25. exec • exec gives spawned process a new address space and loads with contents of new program • Process address space includes: • Executable code • Initialized and uninitialized data • Shared memory and libraries • User stack (kernel allocates for each process)

  26. exec Recall-> if ((exec(“new_program”, ..) < 0) Things exec must do include: • Parse pathname and access executable file • Verify that caller has execute permission on the file • Change caller’s UID/GID to owner of file • Free old address space (not for vfork) • Allocate new address and swap space • Initialize hardware context –most registers set to 0, pc set to entry point of program • C library versions: exec, execl, execv, exece

  27. Process Termination • exit() • exit system call -> calls kernel exit function which terminates a process.

  28. exit • Does many things, including: • Closes all open files • Writes accounting log • Saves resource usage statistics and exit status • Changes state to zombie • Makes init process inherit any live children of existing process • Releases address space and swap space • Wakes parent if it is asleep • Calls swtch() to schedule a new process. • …

  29. Awaiting Process Termination • Parent often needs to know when a child terminates, e.g. when a bg process terminates, shell may want to notify user. • wait system call allows a process to wait for a child to terminate.

  30. wait • Child may have terminated before call- wait must handle that condition also. • wait first checks if caller has deceased or suspended children. If so- immediate return. • If not, wait blocks the caller until a child dies and returns once that happens. • In either case- wait returns PID of deceased child and frees and updates the appropriate structures (i.e., info in PCB)

  31. zombie • When process exits, it remains in zombie state until cleanup by parent. It holds info, e.g.,exit status and resource usage, possibly needed by parent. Parent calls wait to obtain this and free up PCB. • If parent dies before child: init inherits child and when child dies, init calls wait to release PCB info. • If child dies and parent does not call wait- process remains in zombie state until system reboots- shows up in ps listing, user tries to kill, but it is already dead! Also, it continues to use PCB structure.

  32. Interprocess Communication • Kernel provides mechanisms to allow multiple cooperating processes to communicate. Called IPC. • Purposes: • Data transfer • Sharing data • Event notification • Resource sharing

  33. IPC Mechanisms • Common to all Unix variants: • Pipes • Signals (primitive) • Process trace (used by debuggers)

  34. pipes • (for traditional Unix) • A unidirectional, FIFO data stream of fixed size. • Writers add data to end of pipe • Readers retrieve data from front of pipe • Once read, data is removed from pipe and unavailable to other readers

  35. pipe • Process trying to read from an empty pipe will block until more data is written • Process trying to write to a full pipe blocks until another process reads (i.e., removes) data from the pipe

  36. pipe • Pipe system call creates a pipe and returns two file descriptors – one for reading and one for writing • File descriptors are inherited by child process, so they share access to the file. • This allows a pipe to have several readers and writers • Normally, process is shared between 2 processes, each owning one end.

  37. pipe • I/O to pipe is similar to I/O to a file and is performed through read and write system calls to the pipe’s descriptors. • Process is often unaware that file it is reading or writing to/from is a pipe.

  38. Limitations of pipes • Cannot broadcast data to multiple receivers (since reading removes data) • Data in pipe is treated as byte-stream, so cannot specify boundaries if multiple objects are sent. • With multiple readers, writer cannot direct data to specific reader and vice versa.

  39. SVR4 pipes • SVR4 pipes are bidirectional • Pipe system call returns two descriptors, but both are open for reading and writing. Syntax is: • int filedes[2]; • status = pipe (fildes); • Creates 2 independent, FIFO I/O channels represented by 2 descriptors. Data written to fildes[1] can be read from fildes[0] and vice versa.

  40. File Descriptors • Process interface with files via file-related system calls. • File system calls identify files by 2 names: path name and a file descriptor. • File descriptor is integer number identifying an open file within a process. • Each process has a table of open files, starting at fd 0 and going up as more files are opened.

  41. File Descriptors • A file descriptor can be obtained with open() system call, which opens a file named by path name and returns a file descriptor identifying the file • fd= open(“etc/passwd”, mode); • Once opened, an fd can be used for operations on the file • read and write provide basic file I/O

  42. File Descriptors • An fd is eventually closed by close system call or process exit • By default, fd’s 0,1, and 2 are opened automatically by C runtime library and rep. standard input, output, and error.

More Related