System Calls for Process Management

System Calls: The Gateway to the Kernel

An operating system protects its own integrity and ensures fair resource allocation by enforcing a strict boundary between user applications and the kernel. This is typically achieved through two distinct CPU modes:

• User Mode: The normal mode where applications run. In this mode, the CPU has restricted access to hardware and memory to prevent a misbehaving program from crashing the entire system.
• Kernel Mode: A privileged mode where the OS kernel runs. In this mode, the CPU has unrestricted access to all hardware and memory.

A user program cannot directly create a process or access a file on the disk. To perform such privileged operations, it must make a request to the kernel. This formal request mechanism is the system call. When an application makes a system call, the CPU transitions from user mode to kernel mode, a process that involves a context switch into the kernel. The kernel then executes the requested service on the application's behalf and returns the result, switching back to user mode.

The following article provides a concise overview of this crucial relationship between programs and processes, and the role of system calls as the bridge between user mode and kernel mode.

Creating a New Process: The fork() System Call

In UNIX and its derivatives (including Linux and macOS), the sole method for creating a new process is the fork() system call. Its behavior is one of the most unique and powerful concepts in operating systems. When a process (the parent) calls fork(), the OS creates a new process (the child) that is a near-perfect duplicate of the parent.

This duplication includes the parent's address space (code, global variables, heap, and stack), file descriptors, and environment variables. The child process doesn't start from the main() function; instead, its execution begins as if it had also just returned from the fork() call.

The key to managing this is the return value of fork():

• In the parent process, fork() returns the Process ID (PID) of the newly created child.
• In the child process, fork() returns 0.
• If the creation fails, fork() returns a negative value in the parent.

This difference in return values allows the program to branch its logic and execute different code in the parent and child.

The diagram below provides a visual step-by-step walkthrough of what happens during a fork() call, showing how the parent's state is duplicated to create the child.

Running a Different Program: The exec() System Call

Creating a clone of a process is useful, but it's not the whole story. Most of the time, we want to create a new process to run a different program. This is the job of the exec() family of system calls (e.g., execl(), execvp()).

An exec() call replaces the memory image of the current process with a new program. The new program's code and data are loaded from an executable file, and the process starts executing from the new program's main() function. Crucially, exec() does not create a new process; it transforms the existing one. The PID does not change. If the exec() call is successful, it never returns to the original code, as the original code has been completely overwritten.

The combination of fork() and exec() is the standard UNIX pattern for launching a new program:

1. Call fork() to create a child process.
2. In the child process, call exec() to replace the child's program with the new program.

Synchronizing Processes: The wait() System Call

After a fork(), the parent and child processes run concurrently, and the scheduler determines their execution order. However, a parent often needs to wait for its child to complete a task before it continues. The wait() system call provides this synchronization.

When a parent process calls wait(), the OS suspends the parent until one of its children terminates. Once a child terminates (by calling exit() or finishing main), wait() returns in the parent, providing information about the child's termination, such as its exit status.

Using wait() is critical for two reasons:

1. Orchestration: It allows a parent to know when a child's task is done, ensuring a predictable order of operations.
2. Resource Cleanup: It's the primary mechanism for cleaning up terminated child processes. A child process that has terminated but whose parent has not yet called wait() becomes a zombie process. A zombie holds onto its entry in the process table, consuming a system resource. It's the parent's responsibility to "reap" its children with wait() to free this entry.

The following video explains this orchestration and the concept of zombie processes very clearly.

Putting It All Together: How a Shell Works

The separation of fork() and exec() is not an accident; it's a profoundly powerful design. It allows a child process to manipulate its environment after the fork() but before the exec(). The most common example of this is the command-line shell (like bash).

When you type a command, such as cat my_file.txt | grep "error" > results.txt, the shell performs a beautiful dance of process management:

1. The shell calls fork() to create a child process.
2. In the child, before calling exec(), it manipulates its file descriptors. It closes standard output and opens results.txt, and it sets up a pipe() to connect to another process.
3. The child then calls exec() to run cat, grep, etc. Because file descriptors are inherited across an exec() call, the new program's output is automatically redirected without the program itself needing to be aware of it.
4. Meanwhile, the parent shell calls wait() to pause until the child command completes.
5. Once the child finishes, wait() returns, and the shell prints a new prompt, ready for your next command.

The elegance of this design is that simple, single-purpose utilities (cat, grep, wc) can be chained together in powerful ways, without any of them needing to know about redirection or pipes. All the complex setup is handled by the shell in the small window of time between fork() and exec().

Conclusion

In this lesson, we explored the fundamental system calls that applications use to manage processes. These operations are the building blocks for multitasking from the application's perspective.

Here are the key takeaways:

• System calls are the protected interface that allows user-mode programs to request privileged services from the kernel, such as process creation.
• The fork() system call creates a new child process that is a near-identical duplicate of the parent.
• The exec() family of calls replaces the current process's image with a new program, allowing a process to run different code.
• The wait() system call allows a parent to synchronize with a child's termination, retrieve its exit status, and prevent the creation of zombie processes.
• The separation of fork() and exec() is a powerful design pattern that enables features like I/O redirection and pipes, as demonstrated by the UNIX shell.

Now that we understand how processes are created and managed, our next lesson will address a critical question: when multiple processes are ready to run, how does the OS decide which one gets to use the CPU next? We will explore this by comparing several CPU scheduling algorithms, such as First-Come, First-Served (FCFS), Shortest Job First (SJF), and Round Robin.