Templates what and why? Beware copying classes! Templates. A simple example:

Transcription

1 Beware copying classes! Templates what and why? class A { private: int data1,data2[5]; float fdata; public: // methods etc. } A a1,a2; //some work initializes a1... a2=a1; //will copy all data of a2 into a1 Works here, But what would happens if class A stored data in a linked list? Suppose you need a linked list of integers After implementing it, you discover that a list of floats, Windows, and other different types are needed. One way of dealing with it: Cut & paste, and change the type Code duplication if the implementation changes, must propagate change to all instances Proper solution: use templates. Templates Notice for the linked list and other data structures, the logic is the same, only the type is different Templates abstract away from the type of the object Given the template, you tell the compiler what type you want, and it will generate a class/function for you, based on the type This is said to instantiate a template A simple example: template <class T> class Array { public: Array(int size=defaultsize); ~Array() { delete [] ptype; } Array & operator=(const Array &); T& operator[](int offset) { return ptype[offset]; } int getsize() { return m_size; }; private: T * ptype; int m_size; };

2 Notice Using the name The data structure being manipulated is generically referred to as T Most of the implementation is like any other class To declare arrays of different types: Array <int> anintarray; Array <Cat> acatarray; In the implementation: Template <class T> Array <T>::Array(int size) { ptype = new T[size]; for(int i=0;i<size; i++) ptypes[i]=0; } Are the following legal? void somefunction(array <int> &); void somefunction(array <T> &); void somefunction(array &); STL standard template library The creators of C++ wrote a set of template classes for you STL Implements commonly used functionality such as vector, stack, list, deque, map vector was used in A3: Unix Internals std::vector <Token> m_tokens;

3 Overview The kernel Why know the internals? Design high performance applications Design principles are similar across different systems We ll focus on 3 areas: The kernel Processes Memory management Is a special program loaded when the computer is turned on Persists until the system is off or crashes Mostly written in C, but some parts are in assembly: must be super efficient! The kernel is responsible for: Memory management Process management Inter-process communication I/O File management Talking to the kernel & interrupts Interrupting interrupts Processes talk to the kernel via system calls Peripherals talk to the kernel via hardware interrupts Hardware interrupts notify the kernel about an external event (eg. key press, mouse move) Suspends current process to handle interrupt Interrupts are prioritized: 1. Hardware errors 2. Clock 3. Disk I/O 4. Keyboard 5. Software interrupts Interrupts can be interrupted by interrupts of higher priority Interrupts of equal or lower priority are discarded Interrupt handlers must be very fast minimizes chance of discarding other interrupts

4 User and Kernel mode The kernel has many internal data structure such as: Process table one entry for every process Open file table one entry for every open file Do not want these data structures to be corrupted by user processes When user process runs it is in user mode cannot execute privileged instructions Only when the machine is in kernel mode can it access kernel data structures When you make a system call System call code #, parameters loaded into registers Execute trap instruction flip into kernel mode System call code # used as index into a lookup table (system call vector table) System call executes Special return instruction flips machine out of kernel mode Processes To create a new process, must fork() First 3 processes are: Pid 0: sched (cpu scheduler, forks & execs twice) Pid 1: init (created by sched) Pid 2: pageout (created by sched) These are kernel processes All other processes created by init These are user processes Process states 6 possible states: Running currently using the CPU Runnable can use the CPU as soon as it s available Sleeping waiting for an event to occur (eg. read()) Suspended frozen by a SIGSTOP signal. Resumes upon a SIGCONT signal Idle process being created by fork(), not runnable Zombified process has terminated, but it s parent is alive and not accepting the return code

5 Process state diagram Process composition Each process is composed of several components: Code area contains the binary machine instructions Data area contains persistent data Stack area call stack, automatic variables User area open file descriptor,signal handler array etc. Page tables used by memory management system. More on this later. Process table The scheduler Kernel data structure One entry per process. Each entry contains the following info: Process ID, Parent Process ID Real and effective user ID State (running, runnable etc) Location of code, data, stack and user area List of pending signals (signal bitmap) Responsible for allocating CPU time slices to processes CPU time allocated in slices called a time quanta (normally 0.1 seconds) CPU time allocated to processes based on priorities If a process sleeps during execution, another one is selected to run immediately Switch between processes is called a context switch To freeze a process, its program counter, stack pointer etc. are saved

6 A sense of scale Memory management If each CPU cycle is 1 second, then: Cache access (on chip) 2 seconds Memory access 30 seconds Context switch 167 minutes Disk access 162 days Quantum 6.3 years Allows processes that are bigger than total RAM available to execute Memory is divided into fixed size chunks called pages The size of a memory page is typically equal to the size of a disk block (why?) Pages tables and regions What the Page & RAM tables look like Code, data, stack areas of processes not necessarily in logically contiguous memory Each area of contiguous logical address space is a region Each region has a data structure called a page table The page table records the location of each page of memory (either in RAM or on disk) Pages of RAM are allocated to processes only when needed. The RAM table records info. Re. Each page of RAM (used, locked, or free)

7 Address translation Your program deals with logical memory addresses NOT physical memory! Must be mapped to real, physical locations The hardware memory management unit (MMU) is responsible for this MMU does this using the process page tables Address translation The MMU knows the region of each of the code, data and stack areas, know also the starting virtual address (SVA) of each Determines in which area the logical address lies, calculate offset from SVA The size of a page is known, so the offset can be used to calculate the region page number (RPN) and the offset within the region page (ORP) Checks the page table: if the page is in memory, the RPN is replaced by the physical RAM page number If the page is on disk, load the page from disk and restart address translation exec() and memory Kernel allocates page tables for the code, data and stack regions Code and initialized data resides on disk (in the executable). Code and data page tables are set to contain locations of the disk blocks Upon 1 st access, the block is copied into a RAM page, and the page table entry is updated to point to the RAM page Uninitialized data have their page table entries marked as zeroed. Upon 1 st access, allocates a page of RAM, fill it with 0s and updates the page table Page tables and process execution When a process is exec d, initially the pages in the page tables point to the disk blocks where code/data is stored As the process executes and tries to access its code/data, page faults will be generated through memory translation This causes code/data pages to be loaded into RAM

8 exec() and the page table Page Daemon and swap space The swap space is a contiguous chunk of disk space set aside for the transfer of pages to and from RAM For efficiency, the system always tries to keep some physical RAM free for potential page faults The minimum # of pages it tries to keep free is the low water mark When the # of free pages goes below the low water mark, the page daemon wakes up and pages out some RAM pages until a high water mark is reached Thrashing fork() revisited If large # of processes are running on the system, and the amount of RAM available is limited, then the # of page faults increases to the point where most of the CPU time is spent paging in and out from disk This is called thrashing If sched detects thrashing, it ll deactivate processes based on priority and memory usage and swap them to disk until thrashing stops The deactivated processes are eventually reactivated and swapped back into memory (with other processes swapped out) fork() duplicates most process attributes, including memory, open files etc. Copying the memory of processes has 2 problems: The copying is costly, especially if the process is using large amounts of memory It s often unnecessary, because usually exec() is called after fork(), throwing away the process memory anyway

9 Copy on write To avoid unnecessary/costly copying, fork() is implemented as follows: The child s code region entry is set to point to the parent s code page table. The ref count is incremented The child s data and stack page tables are a copy of the parent s (the page table entries point to the same place). The copy on write bit is set for every page table entry for the stack and data areas of both processes The RAM/Disk pages referenced by the page table entries also have their ref count incremented Processing shared pages Reading a shared page: nothing special happens On writing to a shared page, a copy of the page is made. The write goes on the copied page. The original page has its ref count decremented. The copy on write bit is reset if the ref count has dropped to 1. If the page daemon decides to swap out a shared page, the page s ref count is decremented and a copy is swapped out. The page tables for the process being swapped out are updated. The RAM page is not freed until the ref count is 0. When a process exits A little more on wait() The exit code is placed in its process table entry All open file descriptors are closed The ref count of each of its regions are decremented If the ref count of a region drops to 0, the ref count of all the RAM pages and swap pages are decremented RAM/swap pages whose ref count is 0 are deallocated The process table entry is deallocated when the process s parent accepts the exit code wait() returns under 3 circumstances: 1. It doesn t have any children, wait returns with an error code 2. If the child is already a zombie, it is removed from the process table, and the PID and return value is returned. 3. If none of the children are zombies, it goes to sleep and returns when any signals are received.