Chapter 3 Processes Pgs 101 141 CSCI 3431

Chapter 3 – Processes (Pgs 101 – 141) CSCI 3431: OPERATING SYSTEMS

Processes Pretty much identical to a “job” A task that a computer is performing Consists of: 1. Text Section – Program Code 2. Data Section – Heap, Stack, & Free Space 3. Current State – CPU Register Values Ø Program: Ø Process: Ø Thread: Passive entity on disk Active entity in memory A part of a process (Ch. 4)

Process Layout (x 86) c. f. , Text Fig 3. 1

Process States New: Being created Running: Has a CPU, being executed Suspended: Not running (covers both ready and waiting) Ready: Could be running if assigned to a CPU Waiting: Needs something (e. g. , I/O, signal) Terminated: Done

Fig. 3. 2 Process State

Process Control Block (PCB) O/S (Kernel) Data Structure for a process State - ready, etc. Registers – current values, includes PC Scheduling Info – priority, queue address Memory Info – pages tables, base address Accounting Info – owner, parent, CPU use, pid I/O Status Info – open files, devices assigned

The Unix ps command tami@cs: 0~]ps -l F S UID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 1021 17012 17011 0 80 0 - 9848 rt_sig pts/18 00: 00 zsh 0 R 1021 17134 17012 0 80 0 - 1707 - 00: 00 ps pts/18 tami@cs: 0~] F = Flags, S = State, UID = User, PID = Process PPID = Parent, C = CPU % use, PRI = Priority NI = Nice, ADDR = Swap Addr, SZ = Num pages WCHAN = Kernel function where sleeping TTY = Controlling Terminal Device TIME = CPU Time, CMD = File Name Lots of other data is available using options!

Scheduling Queues Happy little places for processes to wait (just like the lines at Starbucks) Job Queue: All processes in the system Ready Queue: All processes ready to run Device Queue(s): Processes waiting for a particular device (each has own queue) Often just a linked list of PCBs

Queueing Diagram (Fig 3. 7)

Scheduler O/S component that selects a process from a queue Ø Long term (job): select process to be loaded into memory (make ready) Ø Short term (cpu): select ready process to run Ø I/O: select process from the I/O queue for that device Context Switch: Changing the executing process on a CPU; requires saving state of outgoing process, restoring state (if any) of incoming process

Process Mix Computers work best when a variety of processes with different needs exist CPU-bound process: most of its life is computations, very little I/O-bound process: most of its life is spent doing I/O, minimal computation Long term scheduling works best if a mix of these is in memory

Medium Term Scheduler Monitors memory and removes some processes which it writes to disk (“swap out”) Later moves the process back to memory so it can be executed (“swap in”) Will cover this more in Ch. 8 Used to free memory of a process that cannot execute (blocked because it needs resources).

Process Creation All processes have a parent Thus there is a process tree Every process has a PID Two step process in Unix 1. Create a new (duplicate) process : fork() 2. Overlay duplicate with new program: exec()

Fork() and Exec() (Fig 3. 10) pid_t pid = fork(); // Duplicate myself if (pid < 0) error(); // No child, parent OK if (pid == 0) { // Child, don’t know own pid execlp(“/bin/ls”, ”ls”, NULL); } else { // Parent w. opt. wait for child completion wait(NULL); printf(“Child complete. n”); }

fork(): Making a COPY The copy is identical. Has same code, same heap, same stack, same variables with same values Only difference is that child has different PID and PPID

Forking After fork(), either child or parent, or both, could be executing – no guarantees here! wait() causes parent to wait for child to terminate exec family of syscalls overlays child process Additional coding must be performed to allow parent and child to communicate (IPC)

Termination Processes terminate with the exit() syscall GCC inserts it for you after the last executable instruction (or a jmp to it if many exit points) Some O/S terminate all children of a terminating process, “cascading termination” Parents can terminate their children Arbitrary processes cannot terminate each other O/S can terminate a process for a variety of reasons (e. g. , security, on errors) Exit value of a terminated process is stored for a while (e. g. , until reboot or PID reused)

Summary (Unix) New processes made by an existing process using FORK New process is a copy of the old Both parent and child are running after the FORK New process must get new program and data using EXEC Parent can WAIT for child or continue Processes terminate using EXIT

Interprocess Communication Efficiency: Save having 2 copies of something by letting it be shared Performance: Sharing results of parallel computations Co-ordination: Synchronising the transfer of results, access to resources etc. Two primary reasons: 1. Coordination/Synchronisation 2. Data transfer

IPC Models (SGG) 1. Shared Memory – common memory location for both processes to read and write 2. Message Passing – kernel acts as a gobetween to receive and send messages (shared memory is managed by the kernel instead) But, really, its always just some kind of shared memory and there are more than two models

IPC Models Shared memory Message passing Mailboxes & Ports Remote Procedure Calls Pipes Interrupts (users to O/S) Signals (limited information content)

Producer-Consumer Problem Producer creates something Consumer uses that product Consumer must wait for it to be produced and fully put into memory Producer must wait for consumer to create space where the product can be put if the space fills up Requires careful communication and synchronisation

Shared Memory O/S normally prevents one process from accessing the memory of another Requires setup to be effective Processes must somehow co-operate to share the memory effectively or else they can overwrite each other’s data Simultaneous writes cause a big mess!

Unix Shared Memory A “key” is used to name the shared segment. Any process with the key can access it. The segment is located using shmget() The segment is attached using shmat() Generally “fast” for doing communication Uses standard Unix permission system Highly useful techniques are possible Read/Write coordination is needed

Message Passing Uses the O/S to receive, buffer, and send a message Uses the send() and receive() syscalls What if a process tries to receive when nothing has been (or will be) sent? Like shared memory, message passing requires careful coding and co-ordination by the two+ processes

Direct Communication Uses process names (PIDs) Requires knowing the PID of everyone we communicate with If a process terminates, must find its PID and delete it Main drawback is maintaining the list of active PIDs we communicate with Send goes to only one process so multiple sends may be needed Works great in many situations though

Indirect Communication Uses mailboxes or ports Mailbox is an O/S maintained location where a message can be dropped off or picked up All mailboxes have a name Multiple processes can read from the mailbox Mailbox can be owned by O/S or a process Still have the problem of communicating the mailbox name/location, but at least now the O/S knows this information as well

Synchronicity (Not the Police Album) Message passing can be either: 1. 2. Blocking / Synchronous Non-Blocking / Asynchronous Synchronous send() waits for receipt before returning Synchronous receive() waits for the send to complete before returning Asynchronous operations return even if no receipt occurs or if data is not available When both are synchronous, we have a “rendezvous”

Buffering 1. Zero Capacity: There is no buffer and data is discarded if the communication is not synchronous 2. Bounded Capacity: The buffer is fixed size and sender blocks when the buffer fills 3. “Infinite” Capacity: O/S allocates more space to buffer as required

Remote Procedure Call (RPC) A protocol designed so that a process on one machine can have computation performed by calling a procedure (function) that is executed by a different process on another machine Issues with endianism, data encoding Must define a common data representation Issues with synchronisation of processes and returning of results

Sockets Associated with Internet-based IPC A socket is an IP address (a machine) and a specific port on that machine We normally don’t see them because WWW services tend to have a default port, e. g. , Port 80 for HTTP Can use 127. 0. 0. 1 (loopback) to test things, e. g. , client and server on same machine http: //en. wikipedia. org/wiki/List_of_TCP_and_UDP_port_numbers

Pipes A connection (with buffer) for sending data Data of any form can be sent Best for one directional communication Can be used two way if emptied between uses Very common in Unix, considered as the most basic form of IPC Named pipes (called FIFOs) are file system entities in Unix

To Do: Complete this week’s lab Finish reading Chapter 3 (pgs 101 -141; this lecture) if you haven’t already