Section 2: Processes

    Processes are very interesting and I enjoyed learning about their architecture. Before reading I wasn't sure what the difference between a program and a process. A program is a set of instructions that are in an inactive state, waiting to be executed by a user. A Process is a program that has been activated by the user via an executable file.

    Processes can be in several different states, the process state and other information are held together in a process control block. The block holds data including the destination and return address of the process. All the above information describes a single-threaded process.

    In a multithreaded architecture the process control block (PCB) can also maintain information about multiple threads of processes. So a PCB could have several processes running all at the same time. Most OS today use a multithreaded architecture, allowing the user to have several processes running even if they are not being actively used, while freeing up space for the processor. 

    Each process has a piece of code called the critical section. While code in the critical section is being executed, no other process can be executing in it's critical section. Only one critical section piece of code can be processed at a time. Therefore the critical-section problem is to define a way to have each process cooperate and allow the processor to complete each critical section code. The conditions for solving the critical-section problem are mutual exclusion, which states that only one critical section can be processed at a time. Second, progress, which determines how each process will determine if they can enter their critical section. Thirdly, bounded waiting, which limits how many times a process can request to enter it's critical section.

    For my concept map I decided to show how a Mutex lock would work when requesting and releasing the lock before and after processing the critical section.