CS110 - Lecture notes 1-20 PDF

Preview

Summary

Notes I took as a student in Jerry Cain's class at Stanford University, CS1110: Principles of Computer Systems....

Description

Lecture 2 1/11/17 F  ilesystems, APIs, and System Calls: -

Even functions in the terminal like ls, cp are coded functions somewhere C has fopen, fclose, scanf, stdin, stdout, etc; C++ has ifstream, ofstream, cout, cin… A system call is something that is technically a function but is so vital that it interacts directly with the OS - Open, read, write, close are all examples of these - Let’s right a copy.c file to do what cp does (copy src dest) int main(int argc, char* argv[]) { assert(argc == 3); int fdin = open(argv[1], O_RDONLY); int fdout = open(argv[2], O_WRONLY | O_CREAT | O_EXCL, 0644); //tests to make sure can open file the dest file or make a new file (returns 4 if new file) //fdin probably returns 3 if successful, a -1 for either indicates failure to open while(true) { char buffer[128]; ssize_t readBytes = read(fdin, buffer, 128); if(readBytes == 0) break; //has already gone through all of src size_t numWritten = 0; while(numWritten < readBytes) { numWritten += write(fdout, buffer + numWritten, readBytes numWritten); } } close(fdin); close(fdout); return 0; } - See lecture slides on website for more complete/thorough implementation Data Structures maintained by OS: - File descriptor table is an array with different descriptors ([in, out, err, ….] - File entry table (array) stores cursor locations and type of file (read, write, etc) - Descriptor table entries map to entry table entries - Entry table is dynamic and changes session to session - Vnode table stores file names and size in bytes (static info about the file) - Entry table nodes also map to vnode entry of the file to which it refers Hardware: - Hardware has a bunch of cells of uniform size - Files store the addresses of the cells (don’t have to be sequential on the hard drive) - Portion of hard drive stores this overhead, also tracks permissions/metadata

Lecture 3 1/13/17 M  ore on Filesystems APIs, Filesystem Design: -

-

API = application program interface Addresses of where memory is stored on hard drive are tracked in inodes - Section of hard drive storage is divided up into smaller blocks to store array of inodes - Then file names and the address where their inodes are stored are kept in the directory - Possible to have singly indirect inodes where an address points to another set of addresses (or doubly indirect etc.) Inodes also store if file/directory, size, name, read/write permissions Alright let’s make a function search.c that finds a requested filename given a root directory: Static void listMatches(char path[], size_t length, const char* pattern) { DIR* dir = opendir(path); //directory variable, knows how to iterate over entries in directory assert(dir != NULL); strcpy(path + length, “/”); while(true) { Struct dirent* de = readdir(dir); //directory entry variable, readdir gets next entry in dir if(de == NULL) break //went through all entries already if(strcmp(de->d_name, “.” == 0 || strcmp(de->d.name, “..”) == 0) continue; //skip over the parent directory or itself so we don’t get caught in infinite loop strcpy(path + length + 1, de->d_name); //add to path Struct stat st; //struct stat has info about a current path lstat(path, &st); //in lecture he used stat(path, &st), populates stat struct with info about path if(S_ISDIR(st.st_mode)) //macro to check if end of path is a directory listMatches(path, length + 1 + strlen(de->d_name), pattern); Else if(S_ISREG(st.st_mode)) //macro to check if it’s a regular file if(strcmp(de->d_name, pattern) == 0) printf(“%s\n”, path); } closedir(dir); } -

So what is a DIR struct? - It has a file descriptor, vnode, static info about file that points to an inode - Also has an index to track which entry in the directory it should return next when readdir is called

Lecture 6 1/23/17: -

-

Type a trailing ‘&’ at the end of a command in the shell to run that process in the background (essentially just making the shell waitpid() for that process to finish in its fork before displaying the command prompt again Commands like “exit” are shell built-ins fork() returns its child’s pid or 0 if it IS the resulting child Can waitpid(pid, &int, 0) for process pid to finish (address of int where status report stored)

- Running a command: Int mysystem(char* command) { Pid_t pid = fork(); if(pid == 0) { //only do this in the child process char* argv[] = {command, NULL}; execvp(argv[0], argv); //if this works, it has transformed the child process and this will never return so the only way we continue is if it failed: printf(“%s not found \n”, command); exit(0); } Int status; waitpid(pid, &status, 0); if(WIFEXITED(status)) return WEXITSTATUS(status); //if exited normally Else return -WTERMSIG(stats); //terminating signal representing abnormal exit, negative so it’s clear this was something bad :0 - We said earlier that the file directory table was unique, but it’s copied by fork (including what it is pointing to - which is why all processes can print to the same screen via stdout - Argv makes entries point to first character of arguments, replaces in place whitespace after a word with \0, argv[argc] alway NULL

Lecture 7 1/25/17: -

-

-

-

-

-

Int pipe(int fds[]) - Fds stores file descriptors for processes - Fds[1] writes its output to the standard input of fds[0] - Helps us move toward being able to have subprocesses - Typedef struct { pid_t pid; int supplyfd; } subprocess_t; See basic pipe example at right: - Pipe populates fds with the 2 file descriptors such that fds[1] is the write end, fds[0] is read end - Data written is buffered by kernel until it is read by read end - This example forks and child read call waits until something is written into the pipe then prints, parent does the writing dup2(int oldfd, int newfd) makes newfd a copy of oldfd - Can use this to make fd[0] the same as STDIN_FILENO (0)

Time for SIGNALS!! Common signal: SIGSEGV (maps to behind the scenes 11) (signal segmentation violation Also: SIGFPE (floating point error), SIGILL, SIGKILL, SIGINT (interrupted, you hit ctrl-c), SIGTSTP (temporary stop, ctrl-z), restarted by SIGCONT (kill -CONT j  obID) Example of handler (handles but doesn’t fix it) SIGCHLD checks if all children have returned

Lecture 8 1/27/17: -

-

-

Invoke waitpid with 3rd argument WNOHANG to stop waitpid from just chilling and waiting for the child process to finish - If there are remaining processes, it will return the pid if one has finished, 0 if none have finished but some are still running, -1 if none still running Here we go signals!! - To do something when a signal occurs, say: signal(SIG__, handler); - Then method will know what to do whenever it sees that signal - To make a process wait until you’re ready for it to send Sigset_t mask; sigemptyset(&mask); sigaddset(&mask, SIG_CHILD); //add a signal to the set sigprocmask(SIG_BLOCK, &mask, NULL); //blocks the SIGCHLD from sending Pid_t pid = fork(); if(pid == 0) { sigprocmask(SIG_UNBLOCK &mask, NULL); //so kids don’t inherit block Dostuff; } Dostuff; sigprocmask(SIG_UNBLOCK, &mask, NULL); //allow signal to send again “This course from now on is all about synchronization issues” -JC There is a function called kill(pid, signal); - Sends a signal to process identified by pid - Not actually necessarily killing anything unless the signal you send is SIGKILL

Lecture 9 1/30/17: -

-

-

-

-

How can so many processes run at the same time thinking that they own all of memory? Say we have 2 processes open both running emacs - Each has its own pid but largely look the same (same text segment—read only) - Initially use the same virtual addresses for the start/end of their segments - Get physical memory twice the size of virtual - One process gets bottom half (same addresses) - Other gets top half (virtual +size of virtual = physical) - But lots of virtual address space will be empty/unused for a given process OS actually tracks pairs of (pid, virtual address) → physical address - Does all this behind the scenes so many processes can be running and truly believe that its virtual addresses are right, but OS actually maps them elsewhere - They are no longer necessarily actually next to one another Translation lookaside buffer TLB is apparently something kinda important Only one process can actually run on the CPU at a time (if only 1 CPU) - Scheduler can flip back and forth rapidly between multiple processes to give the sense that multiple processes are running simultaneously - Stores current state of CPU for that process to pick back up where it left off Music playback: CPU time required to populate buffers but then playback is handled by dedicated hardware that plays from buffers Computer stores list of running threads, ready queue of ready-to-run threads, and blocked queue of threads that are blocked/waiting for something When you download an album, it’ll usually download 3-4 at once - Does this because each individual download is going to be blocked from time to time as it waits for material to be delivered, so it can do it in round-robin so that it can move on to starting another one when one is waiting This is called multi-threading — running multiple execution threads at once to make full use of time/CPU Different threads have different stack segments, but the same text/data/heap segments Pthread_join will wait until given thread is in the ready queue if it is in the blocked queue

Lecture 10 2/1/17: -

-

Printf is a thread-safe process (if it starts in one thread, it’ll finish before another thread takes over the CPU) Multiprocessing: multiple copies of text segment in various virtual address spaces Multithreading: all share text segment, heap segment, just separate chunks of the stack - Run by thread manager controlling who does what when “Race condition” when threads are in contention for shared piece of data in the parent and subsequent processes sometimes get there first and/or parent changes that data before the thread gets the chance to use the value that they wanted In c++, you can insert a lock to make cout thread-safe also - Cout...