Analysis Of An Operating System Paper

Analysis of an Operating System

Dewey Greear

Regis University

Analysis of an Operating System This report will cover the basics of operating systems for centralized computers. I will present these operating system techniques through the use of the FreeBSD operating system. I will begin with a brief overview of the FreeBSD operating system and continue on to discuss basic operating system functions dealing with the kernel, process management and memory management. Furthermore, the fast file system, how to read and write to a file, and network-layer protocols will be examined. The paper will finish up by looking at some of the advantages and disadvantages of the FreeBSD operating system.

FreeBSD is an open source operating system

These are used by setting a flag that is checked as soon as a process is getting ready to exit from the kernel, therefore if this flag is set the interrupt code will be executed instead of exiting the kernel. Software initiated traps are also made by programs when they want the operating system to perform a system call (Bower, 2009).

Process Management

In FreeBSD, the state element of the process structure contains the current value of the process state (McKusick et al., 2014). There are three different state values in this operating system. The states are NEW (undergoing process creation), NORMAL (threads are RUNNABLE, STOPPED, or SLEEPING), and ZOMBIE (going through process termination) (McKusick et al., 2014).

When a process is first made with a fork system call, it is tagged with the label, NEW (McKusick et al., 2014). This state is not changed to NORMAL until the process begins to run. The process will stay in the NORMAL state until the process terminates and it then goes into the ZOMBIE state. The process will remain in the ZOMBIE state until its resources have been let go and it has let the parent process know of its termination status (McKusick et al.,

The major design considerations of mutexes consist of three things. The first consideration is that acquiring and releasing uncontested mutexes needs to be extremely quick. The second consideration is that mutexes need to have information and storage space available in order to support priority propagation. Lastly, a threads use of recursion to get a mutex must be possible if the mutex is initialized to support recursion (FreeBSD Man, 2015).

There are two different categories of mutexes. One category contains mutexes that block and the other category contains those that do not. Threads will block by default when requesting a mutex that is currently held. Most kernel code uses a default lock that permits the thread to be left out of the CPU if it is unable to get the lock (FreeBSD Man, 2015).

Spin mutexes are mutexes that do not enter a sleep state. This mutex will not let go of the CPU when it is unable to get the requested lock, but it will go into a looping motion until the mutex is released by another CPU. This can result in deadlock if a thread that is holding a mutex is interrupted by another thread that is trying to acquire this mutex. To defend against this action, a spin mutex runs inside a critical section in which the interrupts are disabled on that particular CPU.

Lock