Chapter 3 – Processes (Pgs 101 – 141)

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: Passive entity on disk  Process: Active entity in memory  Thread:A part of a process (Ch. 4)

Process Layout (x86) 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 -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S rt_sig pts/18 00:00:00 zsh 0 R pts/18 00:00:00 ps  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  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 go- between 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 over-write 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. Blocking / Synchronous 2. 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 (loopback) to test things, e.g., client and server on same machine

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 ; this lecture) if you haven’t already