DOCSLIB.ORG

Section 7: Wait + Exit in Pintos, Calling Conventions, Midterm Review

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Section 7: Wait + Exit in Pintos, Calling Conventions, Midterm Review Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review CS162 July 17, 2019 Contents 1 Wait and Exit 2 1.1 Thinking about what you need to do..............................2 1.2 Code................................................2 2 Calling Conventions and Argument Passing4 2.1 Calling Conventions.......................................4 3 Midterm Review 5 3.1 Signals and Forks.........................................5 3.2 Spring 2017, MT1 P5......................................6 3.3 Fall 2017, MT1 P2........................................8 1 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 1 Wait and Exit This problem is designed to help you with implementing wait and exit in your project. Recall that wait suspends execution of the parent process until the child process specified by the parameter id exits, upon which it returns the exit code of the child process. In Pintos, there is a 1:1 mapping between processes and threads. 1.1 Thinking about what you need to do "wait" requires communication between a process and its children, usually implemented through shared data. The shared data might be added to struct thread, but many solutions separate it into a separate structure. At least the following must be shared between a parent and each of its children: - Child's exit status, so that "wait" can return it. - Child's thread id, for "wait" to compare against its argument. - A way for the parent to block until the child dies (usually a semaphore). - A way for the parent and child to tell whether the other is already dead, in a race-free fashion (to ensure that their shared data can be freed). 1.2 Code Data structures to add to thread.h for waiting logic: Pseudocode: process_wait (tid_t child_tid) { iterate through list of child processes if child process tid matches tid parameter, call sema_down on the semaphore associated with that child process (when child process exits, it will sema_up on that same semaphore, waking up the parent process) --- after waking --- set exit code to terminated child process's exit code decrease ref_cnt of child //why? need to free memory, "zombie processes" return exit_code } process_exit (void) { sema_up on semaphore that parent might be sleeping on remove all child processes from child process list decrement ref_cnt } Code: struct wait_status { struct list_elem elem; /* `children' list element. */ struct lock lock; /* Protects ref_cnt. */ int ref_cnt; /* 2=child and parent both alive, 1=either child or parent alive, 2 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 0=child and parent both dead. */ tid_t tid; /* Child thread id. */ int exit_code; /* Child exit code, if dead. */ struct semaphore dead; /* 1=child alive, 0=child dead. */ }; struct wait_status *wait_status; /* This process's completion state. */ struct list children; /* Completion status of children. */ Implement wait: - Find the child in the list of shared data structures. (If none is found, return -1.) - Wait for the child to die, by downing a semaphore in the shared data. - Obtain the child's exit code from the shared data. - Destroy the shared data structure and remove it from the list. - Return the exit code. Implement exit: - Save the exit code in the shared data. - Up the semaphore in the data shared with our parent process (if any). In some kind of race-free way (such as using a lock and a reference count or pair of boolean variables in the shared data area), mark the shared data as unused by us and free it if the parent is also dead. - Iterate the list of children and, as in the previous step, mark them as no longer used by us and free them if the child is also dead. - Terminate the thread. 3 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 2 Calling Conventions and Argument Passing 2.1 Calling Conventions Sketch the stack frame of helper before it returns. void helper(char* str, int len) { char word[len]; strncpy(word, str, len); printf("%s", word); return; } int main(int argc, char *argv[]) { char* str = "Hello World!"; helper(str, 13); } 13 str return address saved EBP ! d l ... l e H 4 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 3 Midterm Review 3.1 Signals and Forks Given the following code, write out all possible outputs. pid_t pid; int counter = 3; void rem(int signum) { counter *= 5; printf("counter: %d\n", counter); kill(pid, SIGUSR1); } void emilia(int signum) { counter += 5; printf("counter: %d\n", counter); exit(0); } int main() { pid_t p; int status; signal(SIGUSR1, rem); if ((pid = fork()) == 0) { signal(SIGUSR1, emilia); kill(getppid(), SIGUSR1); while(1); } counter = 1000; printf("counter: %d\n", counter); } counter: 15 counter: 15 counter: 5000 counter: 8 counter: 1000 counter: 5000 counter: 1000 counter: 8 counter: 8 counter: 5000 counter: 1000 counter: 1000 counter: 8 counter: 5000 counter: 50000 counter: 8 5 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 3.2 Spring 2017, MT1 P5 Next Saturday is the international day of Poker. As the owner of the largest poker website worldwide you expect a large number of games being played (and finishing) at any point in time in your website. Consider that players can play more than one game at a time and any two players can play against each other in more than one game simultaneously. For simplicity, we consider each game has exactly two players. The backend system of your poker website contains the following multi-threaded code: queue games_finished_queue; lock_t games_finished_lock; semaphore games_to_process_sem; typedef struct Game { .... } Game; typedef struct Player { lock_t lock; uint64_t n_chips; uint64_t unique_id; } Player; void finish_game(Game *game) { lock_acquire(&games_finished_lock); enqueue(&games_finished_queue, game); lock_release(&games_finished_lock); sema_up(&games_to_process_sem); } void process_finished_games() { lock_acquire(&games_finished_lock); sema_down(&games_to_process_sem); Game *g = pop_queue_front(&games_finished_queue); move_chips(g->player1, g->player2, g->n_chips); lock_release(&games_finished_lock); } void move_chips(Player *player1, Player *player2, uint64_t n_chips) { lock_acquire(&player1->lock); lock_acquire(&player2->lock); player1->n_chips -= n_chips; player2->n_chips += n_chips; lock_release(&player2->lock); lock_release(&player1->lock); } (a) Identify two places in the code where deadlock can occur. If deadlock occurs, use no more than two sentences to explain why it occurs. First, in process finished games(), sema down() can make thread wait on a critical section. Second, move chips() can deadlock if two players play against each other simultaneously. This can lead to two concurrent calls with the same (but swapped) players/arguments. 6 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review move_chips(player1, player2, n1) move_chips(player2, player1, n2) (b) Use the space bellow to change process finished games() and move chips() (or copy if correct) to ensure no deadlocks can occur. Explain succinctly why no deadlock can occur with the newly modified code. Note: a single lock at the beginning and end of move chips is not an accepted solution. void process_finished_games() { // Acquire semaphore outside of critical section sema_down(&games_to_process); lock_acquire(&games_finished); Game* g = pop_queue_front(&games_finished_queue); move_chips(g->player1, g->player2, g->n_chips); lock_release(games_finished);; } void move_chips(Player* player1, Player* player2, uint64_t n_chips) { // acquire locks in well defined order if (player1->unique_id < player2->unique_id) { lock_acquire(&player1->lock); lock_acquire(&player2->lock); } else { lock_acquire(&player2->lock); lock_acquire(&player1->lock); } player1->n_chips -= n_chips; player2->n_chips += n_chips; lock_release(&player1->lock); lock_release(&player2->lock); } 7 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review 3.3 Fall 2017, MT1 P2 Consider the following C program. Assume that all system calls succeed when possible. void *rem(void *args) { printf("Blue: %d\n", *((int *) args)); exit(0); } void *ram(void *args) { printf("Pink: %d\n", ((int *) args)[0]); return NULL; } int main(void) { pid_t pid; pthread_t pthread; int status; //declaring vars int fd = open("emilia.txt", O_CREAT|O_TRUNC|O_WRONLY, 0666); int *subaru = (int *) calloc(1, sizeof(int)); printf("Original: %d\n", *subaru); if (pid = fork()) { *subaru = 1337; pid = fork(); } if (!pid) { pthread_create(&pthread, NULL, ram, (void*) subaru); } else { for (int i = 0; i < 2; i++) waitpid(-1, &status, 0); pthread_create(&pthread, NULL, rem, (void*) subaru); } pthread_join(pthread, NULL); if (*subaru == 1337) dup2(fd, fileno(stdout)); printf("All done!\n"); return 0; } (a) Including the original process, how many processes are created? Including the original thread, how many threads are created? 3 processes and 6 threads. (b) Provide all possible outputs in standard output. 8 CS 162 Summer 2019 Section 7: Wait + Exit in PintOS, Calling Conventions, Midterm Review Original: 0 Original: 0 Original: 0 Pink: 1337 Pink: 0 Pink: 0 Pink: 0 Pink: 1337 All done! All done! All done! Pink: 1337 Blue: 1337 Blue: 1337 Blue: 1337 (c) Provide all possible contents of emilia.txt. All done! (d) Suppose we deleted line 28 (if *subaru == 1337), how would the contents of emilia.txt change (if they do)? All done! All done! (e) What if, in addition to doing the change in part (d), we also move line 12 (where we open the file descriptor) between lines 19 and 20 (exactly after the first if statement)? What would emilia.txt look like then? All done! {or{ a blank file 9.
Load more

Recommended publications
  • Parallel Programming in Unix, Many Programs Run in at the Same Time
    parallelism parallel programming! to perform a number of tasks simultaneously! these can be calculations, or data transfer or…! In Unix, many programs run in at the same time handling various tasks! we like multitasking…! we don’t like waiting… "1 simplest way: FORK() Each process has a process ID called PID.! After a fork() call, ! there will be a second process with another PID which we call the child. ! The first process, will also continue to exist and to execute commands, we call it the mother. "2 fork() example #include <stdio.h> // printf, stderr, fprintf! ! #include <sys/types.h> // pid_t ! } // end of child! #include <unistd.h> // _exit, fork! else ! #include <stdlib.h> // exit ! { ! #include <errno.h> // errno! ! ! /* If fork() returns a positive number, we int main(void)! are in the parent process! {! * (the fork return value is the PID of the pid_t pid;! newly created child process)! pid = fork();! */! ! int i;! if (pid == -1) {! for (i = 0; i < 10; i++)! fprintf(stderr, "can't fork, error %d\n", {! errno);! printf("parent: %d\n", i);! exit(EXIT_FAILURE);! sleep(1);! }! }! ! exit(0);! if (pid == 0) {! }// end of parent! /* Child process:! ! * If fork() returns 0, it is the child return 0;! process.! } */! int j;! for (j = 0; j < 15; j++) {! printf("child: %d\n", j);! sleep(1);! }! _exit(0); /* Note that we do not use exit() */! !3 why not to fork fork() system call is the easiest way of branching out to do 2 tasks concurrently. BUT" it creates a separate address space such that the child process has an exact copy of all the memory segments of the parent process.
    [Show full text]
  • Name Synopsis Description
    Perl version 5.10.0 documentation - vmsish NAME vmsish - Perl pragma to control VMS-specific language features SYNOPSIS use vmsish; use vmsish 'status';# or '$?' use vmsish 'exit'; use vmsish 'time'; use vmsish 'hushed'; no vmsish 'hushed'; vmsish::hushed($hush); use vmsish; no vmsish 'time'; DESCRIPTION If no import list is supplied, all possible VMS-specific features areassumed. Currently, there are four VMS-specific features available:'status' (a.k.a '$?'), 'exit', 'time' and 'hushed'. If you're not running VMS, this module does nothing. vmsish status This makes $? and system return the native VMS exit statusinstead of emulating the POSIX exit status. vmsish exit This makes exit 1 produce a successful exit (with status SS$_NORMAL),instead of emulating UNIX exit(), which considers exit 1 to indicatean error. As with the CRTL's exit() function, exit 0 is also mappedto an exit status of SS$_NORMAL, and any other argument to exit() isused directly as Perl's exit status. vmsish time This makes all times relative to the local time zone, instead of thedefault of Universal Time (a.k.a Greenwich Mean Time, or GMT). vmsish hushed This suppresses printing of VMS status messages to SYS$OUTPUT andSYS$ERROR if Perl terminates with an error status. and allowsprograms that are expecting "unix-style" Perl to avoid having to parseVMS error messages. It does not suppress any messages from Perlitself, just the messages generated by DCL after Perl exits. The DCLsymbol $STATUS will still have the termination status, but with ahigh-order bit set: EXAMPLE:$ perl -e"exit 44;" Non-hushed error exit%SYSTEM-F-ABORT, abort DCL message$ show sym $STATUS$STATUS == "%X0000002C" $ perl -e"use vmsish qw(hushed); exit 44;" Hushed error exit $ show sym $STATUS $STATUS == "%X1000002C" The 'hushed' flag has a global scope during compilation: the exit() ordie() commands that are compiled after 'vmsish hushed' will be hushedwhen they are executed.
    [Show full text]
  • UNIX X Command Tips and Tricks David B
    SESUG Paper 122-2019 UNIX X Command Tips and Tricks David B. Horvath, MS, CCP ABSTRACT SAS® provides the ability to execute operating system level commands from within your SAS code – generically known as the “X Command”. This session explores the various commands, the advantages and disadvantages of each, and their alternatives. The focus is on UNIX/Linux but much of the same applies to Windows as well. Under SAS EG, any issued commands execute on the SAS engine, not necessarily on the PC. X %sysexec Call system Systask command Filename pipe &SYSRC Waitfor Alternatives will also be addressed – how to handle when NOXCMD is the default for your installation, saving results, and error checking. INTRODUCTION In this paper I will be covering some of the basics of the functionality within SAS that allows you to execute operating system commands from within your program. There are multiple ways you can do so – external to data steps, within data steps, and within macros. All of these, along with error checking, will be covered. RELEVANT OPTIONS Execution of any of the SAS System command execution commands depends on one option's setting: XCMD Enables the X command in SAS. Which can only be set at startup: options xcmd; ____ 30 WARNING 30-12: SAS option XCMD is valid only at startup of the SAS System. The SAS option is ignored. Unfortunately, ff NOXCMD is set at startup time, you're out of luck. Sorry! You might want to have a conversation with your system administrators to determine why and if you can get it changed.
    [Show full text]
  • HP Decset for Openvms Guide to the Module Management System
    HP DECset for OpenVMS Guide to the Module Management System Order Number: AA–P119J–TE July 2005 This guide describes the Module Management System (MMS) and explains how to get started using its basic features. Revision/Update Information: This is a revised manual. Operating System Version: OpenVMS I64 Version 8.2 OpenVMS Alpha Version 7.3–2 or 8.2 OpenVMS VAX Version 7.3 Windowing System Version: DECwindows Motif for OpenVMS I64 Version 1.5 DECwindows Motif for OpenVMS Alpha Version 1.3–1 or 1.5 DECwindows Motif for OpenVMS VAX Version 1.2–6 Software Version: HP DECset Version 12.7 for OpenVMS Hewlett-Packard Company Palo Alto, California © Copyright 2005 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Java is a US trademark of Sun Microsystems, Inc. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation.
    [Show full text]
  • Making Processes
    Making Processes • Topics • Process creation from the user level: • fork, execvp, wait, waitpid • Learning Objectives: • Explain how processes are created • Create new processes, synchronize with them, and communicate exit codes back to the forking process. • Start building a simple shell. 11/8/16 CS61 Fall 2016 1 Recall how we create processes: fork #include <unistd.h> pid_t ret_pid; ret_pid = fork(); switch (ret_pid){ case 0: /* I am the child. */ break; case -1: /* Something bad happened. */ break; default: /* * I am the parent and my child’s * pid is ret_pid. */ break; } 11/8/16 CS61 Fall 2016 2 But what good are two identical processes? • So fork let us create a new process, but it’s identical to the original. That might not be very handy. • Enter exec (and friends): The exec family of functions replaces the current process image with a new process image. • exec is the original/traditional API • execve is the modern day (more efficient) implementation. • There are a pile of functions, all of which ultimately invoke execve; we will focus on execvp (which is recommended for Assignment 5). • If execvp returns, then it was unsuccessful and will return -1 and set errno. • If successful, execvp does not return, because it is off and running as a new process. • Arguments: • file: Name of a file to be executed • args: Null-terminated argument vector; the first entry of which is (by convention) the file name associated with the file being executed. 11/8/16 CS61 Fall 2016 3 Programming with Exec #include <unistd.h> #include <errno.h> #include <stdio.h> pid_t ret_pid; ret_pid = fork(); switch (ret_pid){ case 0: /* I am the child.
    [Show full text]
  • Linux-Kernel
    linux-kernel #linux- kernel Table of Contents About 1 Chapter 1: Getting started with linux-kernel 2 Remarks 2 Versions 2 Examples 2 Installation or Setup 2 Download extract and enter to the kernel directory 2 Build the dependencies, compile the kernel and modules. 3 Chapter 2: Creation and usage of Kernel Threads 4 Introduction 4 Examples 4 Creation of kernel threads 4 Chapter 3: Event Tracing 6 Examples 6 Tracing I2C Events 6 Chapter 4: Fork System call 7 Examples 7 fork() system call 7 Chapter 5: How to find the right person for help. 9 Introduction 9 Examples 9 Find the "likely" maintainers for the FTDI USB serial converter 9 Chapter 6: Linux Hello World Device driver 10 Examples 10 An empty kernel module 10 Building and running the module 10 Chapter 7: Linux: Named Pipes(FIFO) 12 Examples 12 What is Named Pipe (FIFO) 12 Credits 13 About You can share this PDF with anyone you feel could benefit from it, downloaded the latest version from: linux-kernel It is an unofficial and free linux-kernel ebook created for educational purposes. All the content is extracted from Stack Overflow Documentation, which is written by many hardworking individuals at Stack Overflow. It is neither affiliated with Stack Overflow nor official linux-kernel. The content is released under Creative Commons BY-SA, and the list of contributors to each chapter are provided in the credits section at the end of this book. Images may be copyright of their respective owners unless otherwise specified. All trademarks and registered trademarks are the property of their respective company owners.
    [Show full text]
  • HP Openvms Utility Routines Manual
    HP OpenVMS Utility Routines Manual Order Number: BA554-90019 June 2010 This manual describes the OpenVMS utility routines, a set of routines that provide a programming interface to various OpenVMS utilities. Revision/Update Information: This manual supersedes the HP OpenVMS Utility Routines Manual, OpenVMS Alpha Version 8.3. Software Version: OpenVMS Version 8.4 for Integrity servers OpenVMS Alpha Version 8.4 Hewlett-Packard Company Palo Alto, California © Copyright 2010 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. ZK4493 The HP OpenVMS documentation set is available on CD. This document was prepared using DECdocument, Version 3.3-1B. Contents Preface ............................................................ xvii 1 Introduction to Utility Routines 2 Access Control List (ACL) Editor Routine 2.1 Introduction to the ACL Editor Routine ........................... ACL–1 2.2 Using the ACL Editor Routine: An Example ....................... ACL–1 2.3 ACL Editor Routine . ........................................ ACL–2 ACLEDIT$EDIT ...........................................
    [Show full text]
  • The Big Picture So Far Today: Process Management
    The Big Picture So Far From the Architecture to the OS to the User: Architectural resources, OS management, and User Abstractions. Hardware abstraction Example OS Services User abstraction Processor Process management, Scheduling, Traps, Process protection, accounting, synchronization Memory Management, Protection, virtual memory Address spaces I/O devices Concurrency with CPU, Interrupt Terminal, mouse, printer, handling system calls File System File management, Persistence Files Distributed systems Networking, security, distributed file Remote procedure calls, system network file system System calls Four architectures for designing OS kernels Computer Science CS377: Operating Systems Lecture 4, page 1 Today: Process Management • A process as the unit of execution. • How are processes represented in the OS? • What are possible execution states and how does the system move from one state to another? • How are processes created in the system? • How do processes communicate? Is this efficient? Computer Science CS377: Operating Systems Lecture 4, page 2 What's in a Process? • Process: dynamic execution context of an executing program • Several processes may run the same program, but each is a distinct process with its own state (e.g., MS Word). • A process executes sequentially, one instruction at a time • Process state consists of at least: ! the code for the running program, ! the static data for the running program, ! space for dynamic data (the heap), the heap pointer (HP), ! the Program Counter (PC), indicating the next instruction, ! an execution stack with the program's call chain (the stack), the stack pointer (SP) ! values of CPU registers ! a set of OS resources in use (e.g., open files) ! process execution state (ready, running, etc.).
    [Show full text]
  • 6.087 Practical Programming in C, Lecture 14
    Outline Review Inter process communication Signals Fork Pipes FIFO Spotlights 1 6.087 Lecture 14 – January 29, 2010 Review Inter process communication Signals Fork Pipes FIFO Spotlights 2 Review: multithreading • Race conditions • non-determinism in thread order. • can be prevented by synchronization • atomic operations necessary for synchronization • Mutex: Allows a single thread to own it • Semaphores: Generalization of mutex, allows N threads to acquire it at a time. • P(s) : acquires a lock • V(s) : releases lock • sem_init(),sem_destroy() • sem_wait(),sem_trywait(),sem_post() • Other problems: deadlock, starvation 2 Sockets • <sys/socket.h> • enables client-server computing • Client: connect() • Server: bind(),listen(),accept() • I/O: write(),send(),read(),recv() 3 6.087 Lecture 14 – January 29, 2010 Review Inter process communication Signals Fork Pipes FIFO Spotlights 4 Preliminaries • Each process has its own address space. Therefore, individual processes cannot communicate unlike threads. • Interprocess communication: Linux/Unix provides several ways to allow communications • signal • pipes • FIFO queues • shared memory • semaphores • sockets 4 <signals.h> • Unix/Linux allows us to handle exceptions that arise during execution (e.g., interrupt, floating point error, segmentation fault etc.). • A process recieves a signal when such a condition occurs. void (∗signal(int sig,void(∗handler)(int )))( int ) • determines how subsequent signals will be handled. • pre-defined behavior: SIG_DFL (default), SIG_IGN (ignore) • returns the previous handler. 5 <signal.h> Valid signals: SIGABRT abnormal termination SIGFPE floating point error SIGILL illegal instruction SIGINT interrupt SIGSEGV segmentation fault SIGTERM termination request SIGBUS bus error SIGQUIT quit The two signals SIGSTOP,SIGKILL cannot be handled. 6 <signal.h> int raise( int sig) can be used to send signal sig to the program.
    [Show full text]
  • Lecture 4: September 13 4.1 Process State
    CMPSCI 377 Operating Systems Fall 2012 Lecture 4: September 13 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 4.1 Process State 4.1.1 Process A process is a dynamic instance of a computer program that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. A computer program itself is just a passive collection of instructions, while a process is the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several windows of the same program typically means more than one process is being executed. The state of a process consists of - code for the running program (text segment), its static data, its heap and the heap pointer (HP) where dynamic data is kept, program counter (PC), stack and the stack pointer (SP), value of CPU registers, set of OS resources in use (list of open files etc.), and the current process execution state (new, ready, running etc.). Some state may be stored in registers, such as the program counter. 4.1.2 Process Execution States Processes go through various process states which determine how the process is handled by the operating system kernel. The specific implementations of these states vary in different operating systems, and the names of these states are not standardised, but the general high-level functionality is the same. When a process is first started/created, it is in new state. It needs to wait for the process scheduler (of the operating system) to set its status to "new" and load it into main memory from secondary storage device (such as a hard disk or a CD-ROM).
    [Show full text]
  • Pid T Fork(Void); Description: Fork Creates a Child Process That Differs
    pid_t fork(void); Description: fork creates a child process that differs from the parent process only in its PID and PPID, and in the fact that resource utilizations are set to 0. File locks and pending signals are not inherited. Returns: On success, the PID of the child process is returned in the parent's thread of execution, and a 0 is returned in the child's thread of execution. int execve(const char *filename, char *const argv [], char *const envp[]); Description: execve() executes the program pointed to by filename. filename must be either a binary executable, or a script. argv is an array of argument strings passed to the new program. envp is an array of strings, conventionally of the form key=value, which are passed as environment to the new program. Returns: execve() does not return on success, and the text, data, bss, and stack of the calling process are overwritten by that of the program loaded. pid_t wait(int *status); pid_t waitpid(pid_t pid, int *status, int options); Description: The wait function suspends execution of the current process until a child has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. The waitpid function suspends execution of the current process until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called \zombie" process), the function returns immediately.
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]