os202

Logo

OS202 - johanessteven19 - Updated Weekly throughout the semester!

View the Project on GitHub johanessteven19/os202

Back to Home


Top 10 List of Week 06

  1. Processes.
    A process, in the context of computers, is the execution of programs. Any computer program is counted, from the simple spell-checking programs that run in the background, to the heaviest of programs, such as video games, internet browsers, etc. These processes are executed in the environment of an Operating System, and an OS is able to handle multiple processes at once.

  2. Processes vs Programs.
    Although we have learnt that a process is a running program, it does not mean that process = program. The difference can be easily proven by simply running the Task Manager of the OS and seeing which programs are running vs. which processes are being executed.
    • A process will be terminated after it is done being executed. A program however, will simply close down and stay on the computer until it is deleted.
    • A process is created during its execution and will then be loaded onto the main memory. A program is first created before execution and will be stored in the secondary memory.
    • A process will require a lot of resources from the CPU, memory address, and I/O devices durign its runtime. A program will only need memory space where the running instructions of the program is stored.
  3. Process Layout.
    We know that when a program is loaded into the memory to be executed, it will become a process. This created process can then be divided into 4 different sections, each with their distinct roles.
    • Stack, which is the section that stores temporary data regarding the method parameters, return addresses, and local variables of the program.
    • Heap, which is the section that dynamically allocates memory into a process during its runtime.
    • Text, which is the section that includes the current activity of the process. This is done by noting down the values of the Program Counter and contents of the processor’s registers.
    • Data, this section stores the global and static variables that may have been created during runtime.
  4. Executing a process.
    We now know that a process will only survive until the program is done running. During its lifetime, it will pass through several phases, or states, depending on its current role.
    • Start state, which is the initial state when the process is first created.
    • Ready state, the state where the process is waiting for its allocated processor resources. The OS will allocate processing power to Ready processes.
    • Running state, the process is currently executing its assigned instructions. From here, the process may either go back to Ready state, or to Waiting state, discussed next.
    • Waiting state, the process will enter this phase when it is waiting for more resources, user inputs, or for a file to be available, before going back to Ready state to execute instructions once more.
    • Exit state, the process is terminated by the OS once it is done executing instructions. The terminated process will then be removed from the main memory.
  5. Process Control Block.
    The Process Control Block (PCB) is the data structure maintained by the OS that represents every single process in the OS. A PCB will store informations about each process to keep track of it. The informations stored are:
    • Process State, either Ready, Running, Waiting, etc.
    • Process Privileges, to keep track of which resources are available to the process.
    • Process ID, to identify each process in the OS.
    • Pointer, the pointer to the parent process.
    • Program Counter, the pointer to the address of the next instruction to be executed.
    • CPU Registers, running processes are stored in these registers to be executed.
    • CPU Scheduling Information, shows which process has priority to be executed first and information about process execution schedules.
    • Memory Management Information, informations about the page table, memory limits, etc.
    • Accounting Information, amount of CPU needed for the execution, time limits, execution IDs, etc.
    • I/O Status Information, information regarding I/O devices accessible by the process.
  6. Process scheduling.
    Process scheduling happens when running process is removed from the CPU and another process is selected by the process manager to be executed next. The selection is done based on a pre-determined strategy. This allows for the efficient loading and parallel execution of processes into the executable memory. There are three important process scheduling queues that is maintained by the OS:
    • Job Queue, keeps all processes in the system.
    • Ready Queue, keeps a set of all processes stored in the main memory to be ready and waiting to be executed. Every new process will be placed in this queue.
    • Device Queue, filled with every process that is blocked by the unavailability of a specific I/O device to be executed.
  7. Threads.
    Threads are basic units of CPU utilization, each one consisting of a Program Counter, a stack, a set of registers, and a thread ID. In single-threaded applications, processes will be controlled by a single thread, meaning that there will only be one Program Counter, and only one set of instructions to be executed at any given moment. The opposite of that is the multi-threaded process, in which there could exist multiple threads in a single process, with their own Program Counters, stacks, and sets of registers. They however will still share a common code, data, and files.

  8. Process vs. Thread.
    • A process will need a lot of resources to be executed, while a thread is very light weight.
    • When multiple processes are executed at the same time, each one will execute the same code, but will take up their own memory and file resources. In multiple threads on the other hand, they will share the same set of open files and child processes.
    • To switch processes, the OS has to be notified. To switch threads, we don’t need to interact with the OS, thus reducing time and resource needed.
    • When a previous process is blocked, then the next processes will not be able to be executed until it is unblocked again. This is not true for threads, which can run a second thread when the first one is blocked.
    • A process will run independently of another process, while a thread can read or write the other thread’s data.
  9. Implementing threads.
    There are two main ways of implementing threads, which are:
    • User Level Threads, which are user-managed. The thread management kernel will not be aware of the running threads, therefore the thread library itself will contain code for the creation and destruction of threads, thread scheduling, and saving/restoring threads. This type of threads is much simpler, not requiring Kernel mode privileges, able to be run on any OS, and faster to be created and managed. They however, will not be able to take advantage of multiprocessing.
    • Kernel Level Threads, which are OS-managed threads acting on the kernel. The kernel will be responsible for managing the existing threads. This allows the kernel to be able to schedule multiple threads from the same process on multiple processes at the same time, therefore granting much higher efficiency. This type of threads however, will be slower to create and manage than the User Level Threads. Also, when switching control from one thread to another, they will have to access the Kernel first, before being able to switch to the other thread.
  10. Multithreading models.
    There are three main models of multithreading, each with their own uses:
    • Many-to-Many Model. This model will multiplex any number of user level threads into any number of kernel level threads that are equal or less to the number of user level threads. This is useful because the developer is able to create as many threads as they want and they will be able to run parallel to the kernel level threads on a multi-processor machine. This model will provide the best accuracy on conccurency compared to the other models.
    • Many-to-One Model. This model will map any number of user level threads into a single kernel level thread. These threads will be managed by the thread library (e.g. Windows, Pthreads, Java threading). This model will not allow for parallel execution, as only a single thread at a time can access the kernel. This model will only be implemented if the user level thread libraries are not supported by the OS.
    • One-to-One Model. This model will map a single user level thread into its corresponding kernel level thread. This allows for more conccurency to occur compared to the previous model. This model will also let a separate thread to run when the first thread generate a blocking system call. However, this also means that the more user level threads there are, the more kernel level threads are created.