• The Clone Conundrum
  • Background
  • Task
• Mystery of the Missing Command
  • Background
  • Scenario
• The Case of the Cloned Counter
• The Case of the Shared Counter (mmap edition)
• The Case of the Shared Counter (pipe edition)
  • Further Notes
• Ghosts of the Dead
• Race Against the Shell
  • Job Control
  • Common UNIX Job Control Signals
  • Task
• MS-DOS vs FreeBSD: A Process Story
• State of Confusion
• The Phantom Thread
  • Background
  • Background
  • Scenario
• The Forgotten Join
• Stack vs Heap: The Return Trap
  • Background
  • Task
• Mapping Mayhem: One-to-One or Many-to-Many?
• Fault Isolation
• Heavyweight Messaging

50.005 Computer System Engineering
Information Systems Technology and Design
Singapore University of Technology and Design
Natalie Agus (Summer 2025)

Processes and Threads

The Clone Conundrum

A student writes a C program that opens a file and then calls fork(). Both the parent and child continue to write to the file. However, the resulting file contents appear garbled, with overlapping or duplicated lines. The student is surprised. They expected the two processes to behave independently and becomes unsure about what fork() actually duplicates and whether file descriptors or file offsets are shared. The unexpected corruption makes them question how resources are managed between parent and child.

Background

In Unix-like operating systems, the fork() system call is used to create a new process by duplicating the calling process. The newly created process, known as the child, receives a copy of the parent’s memory space, register state, and file descriptor table. This allows the child to begin execution as a near-exact replica of the parent, resuming at the instruction immediately following the fork() call.

A subtle but important aspect of fork() is how it handles open file descriptors. While the file descriptor table is copied, the underlying file descriptions (which include the file offset and access mode) are shared. This means that if both parent and child write to the same file descriptor, they are writing through a shared offset, and their operations can interfere with one another unless properly synchronized.

Understanding how fork() interacts with file descriptors and other process resources is critical for writing correct concurrent programs. Misunderstandings in this area often lead to race conditions, data corruption, or unpredictable behavior, especially when multiple processes interact with shared I/O resources.

Task

Answer the following questions:

1. What parts of a process are copied and what are shared between parent and child after a fork()?
2. Why can writing to the same file descriptor in both parent and child lead to race conditions or data corruption?
3. If the parent wants to avoid interference, what should they do after fork()?

Hints:

• fork() duplicates the entire process memory space, including file descriptors.
• Open file descriptors refer to the same underlying file offset unless explicitly changed.
• The child continues from the same program counter as the parent, immediately after the fork() call.
• Use close() or dup2() strategically to manage file descriptor interference.

Mystery of the Missing Command

Background

The exec family of system calls in Unix-like operating systems allows a running process to replace its current memory image with a new program. Unlike fork(), which creates a separate child process, exec() transforms the current process into a new one without changing its process ID or creating a new execution thread. All code, data, and stack segments of the original program are replaced, and the process begins execution from the entry point of the new program.

This behavior has important implications in scripting contexts. When a shell script invokes exec, the shell process itself is replaced by the specified program. As a result, control does not return to the script after the exec call. The script effectively terminates at that point. If exec is used at the top level of an interactive shell session, it can even terminate the session itself.

Understanding the semantics of exec() is critical for correctly managing control flow in scripts and for designing process lifecycles in larger systems. Misusing exec() often leads to confusion, as the process replacement is irreversible and does not allow the original program to resume execution.

Scenario

While experimenting with shell scripts, a student writes a line that uses exec ls. Instead of listing the directory and continuing with the rest of the script, the shell seems to vanish, the script ends abruptly, and control doesn’t return as expected. In some cases, the terminal session itself closes. The student is caught off guard and begins to suspect a bug, not realizing that exec fundamentally changes how the process behaves.

Answer the following questions:

1. What is the effect of calling exec() in a process that is already running?
2. How does exec() differ from fork() in terms of control flow and process replacement?
3. Why does using exec ls in a shell script cause the script to terminate afterward?

Hints:

• exec() replaces the current process image with a new one.
• After a successful exec(), there is no return to the original code.
• exec does not create a new process, it transforms the current one.
• In a shell script, exec ls means the shell process is overwritten by ls.

The Case of the Cloned Counter

You’re helping your teammate debug a strange issue in a C program that involves process creation. The program uses fork() to spawn a child process. Both parent and child increment a shared counter variable in a loop, and print it out to a file.

Here’s a simplified version of the code:

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int counter = 0;

int main() {
    FILE *f = fopen("log.txt", "w");
    if (f == NULL) return 1;

    pid_t pid = fork();

    for (int i = 0; i < 5; i++) {
        counter++;
        fprintf(f, "PID %d: counter = %d\n", getpid(), counter);
    }

    if (pid > 0) wait(NULL);
    fclose(f);
    return 0;
}

When you inspect the contents of log.txt, you find that both processes wrote five lines, but the counter values overlap. For example, both processes print counter = 1, counter = 2, etc. You expected the values to continue incrementing from 6 to 10 in the child. This isn’t what happens.

Answer the following questions:

1. Explain why the counter variable is not shared between parent and child after the fork().
2. Describe what happens to the standard memory, open file descriptor, and file offset in this program after fork().
3. Suppose you want both processes to share and update the same counter variable. What approaches could you use? Compare at least two.
4. If the file writes had also interleaved or corrupted each other, what might be the cause? How would you fix it?

Hints:

• fork() duplicates memory: the parent and child get separate copies of global variables.
• The counter in each process is an independent integer stored in separate address spaces.
• fopen() returns a file descriptor that refers to the same open file description across fork(), meaning they share the file offset.
• To truly share memory, consider using mmap() or a shared memory segment (e.g., shm_open(), mmap()), or use threads instead of processes.
• File I/O issues could arise from buffered output or lack of flushing. Use fflush(f) or unbuffered I/O to ensure correctness.

The Case of the Shared Counter (mmap edition)

You now refactor the previous program to try actual shared memory. You use mmap() to create a counter that both parent and child can access and modify. Here’s the updated code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    int *counter = mmap(NULL, sizeof(int),
                        PROT_READ | PROT_WRITE,
                        MAP_SHARED | MAP_ANONYMOUS,
                        -1, 0);
    if (counter == MAP_FAILED) return 1;

    *counter = 0;

    pid_t pid = fork();
    if (pid < 0) return 1;

    for (int i = 0; i < 5; i++) {
        (*counter)++;
        printf("PID %d: counter = %d\n", getpid(), *counter);
        usleep(100000); // simulate work
    }

    if (pid > 0) wait(NULL);
    munmap(counter, sizeof(int));
    return 0;
}

Now both processes increment the same memory, but new issues emerge: sometimes you see the same number printed twice, or values skip.

Answer the following questions:

1. Why does mmap() work here while a global variable did not?
2. Why do some counter values appear duplicated or skipped?
3. Propose a fix to ensure both processes safely update the counter without data races.
4. Could this still fail if printing were done to a shared file? Why?

Hints:

• mmap(... MAP_SHARED ...) creates shared memory visible across fork().
• The race occurs because (*counter)++ is not atomic, it’s a read-modify-write.
• Use fcntl locks, pthread_mutex_t in shared memory, or Linux futexes for synchronization.
• printf() is buffered per process and may reorder output unpredictably.

The Case of the Shared Counter (pipe edition)

This time, you try a pipe-based approach to solve the problem differently. Instead of sharing memory, the child sends its counter values to the parent via a pipe. Here’s the revised code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    int pipefd[2];
    if (pipe(pipefd) == -1) return 1;

    pid_t pid = fork();
    if (pid < 0) return 1;

    if (pid == 0) {
        // Child: close read end, write counter values
        close(pipefd[0]);
        for (int i = 1; i <= 5; i++) {
            dprintf(pipefd[1], "Child PID %d: counter = %d\n", getpid(), i);
            usleep(100000);
        }
        close(pipefd[1]);
    } else {
        // Parent: close write end, read from child
        close(pipefd[1]);
        char buffer[128];
        while (read(pipefd[0], buffer, sizeof(buffer)-1) > 0) {
            buffer[sizeof(buffer)-1] = '\0'; // ensure null-terminated
            printf("Parent received: %s", buffer);
        }
        close(pipefd[0]);
        wait(NULL);
    }

    return 0;
}

In this version, only the child counts, and the parent prints what it receives.

Answer the following questions:

1. What problem does this approach avoid, compared to shared memory?
2. Why is this version free from data races on the counter value?
3. Suppose you wanted both parent and child to send messages, how would you modify the pipe(s)?
4. What are some downsides of this design compared to the mmap() approach?

Hints:

• Pipes are unidirectional, they serialize output through the kernel buffer.
• Only the child modifies the counter, so no race occurs.
• To make communication two-way, you need a second pipe or use socketpair().
• You lose shared state, so the parent cannot directly modify the counter.

Further Notes

IPC is essential when separate processes need to coordinate or exchange data. Two primary IPC models are shared memory and message passing. In the shared memory model, multiple processes map a common memory region (e.g., using mmap()), allowing direct access to shared variables. This model is efficient but requires careful synchronization (e.g., mutexes or semaphores) to avoid race conditions.

In contrast, the message passing model enforces stricter isolation between processes. Communication occurs through explicit system calls such as write() and read(), and the kernel acts as an intermediary. Pipes are a classic example of message passing IPC in Unix-like systems. A pipe provides a unidirectional channel through which one process can send data to another. This helps serialize communication and reduce the risk of data races, especially when only one process writes and the other reads.

The code in this problem demonstrates a simple parent-child interaction using a pipe. Rather than sharing a counter variable directly, the child sends its updates to the parent through a pipe. The parent reads and prints the received messages, illustrating a safe and structured approach to communication without shared state.

This problem contrasts with shared memory designs and raises useful questions about synchronization, data integrity, and bidirectional communication in IPC.

Ghosts of the Dead

A student writes a C program that spawns several child processes using fork(). Each child completes its task and exits, but the student notices that their process IDs remain in the system with a “Z” status, indicating zombie processes. As more children are created, the number of zombies grows steadily. Although the children have clearly terminated, they still linger in the process table, leading the student to suspect a resource leak or a flaw in their process management.

Answer the following questions:

1. What is a zombie process, and how is it different from a running or stopped process?
2. Why do zombie processes appear when the parent does not call wait()?
3. How can the parent properly clean up after its children to avoid this problem?

Hints:

• A zombie process has terminated, but its exit status has not been collected.
• The OS retains minimal information about the process (PID, exit code) for the parent to retrieve.
• If the parent doesn’t call wait(), the process table entry cannot be freed.
• Use wait() or waitpid() to reap child processes.
• If the parent dies first, init or systemd adopts the child and reaps it.

Race Against the Shell

While running a long-running simulation in the terminal, a student tries two different approaches: launching it normally with ./simulator and then again using ./simulator & to run it in the background. They observe that the foreground job blocks the shell, preventing them from typing further commands until it finishes, while the backgrounded version immediately returns control to the prompt.

Curious, the student begins experimenting with multiple background jobs and notices differences in responsiveness, I/O behavior, and CPU usage. In some cases, background jobs seem to be throttled or behave inconsistently. This leads the student to question how the shell manages job execution, whether the OS treats foreground and background processes differently, and why performance varies depending on how the job was launched.

Answer the following questions:

1. What’s the key difference between foreground and background processes in terms of shell behavior?
2. Who controls scheduling: the shell, or the OS?
3. Why might background jobs behave differently in terms of I/O or CPU usage?

Hints:

• A foreground job is directly connected to the shell’s standard input/output.
• Background jobs still run but cannot interact with the terminal by default.
• The shell regains control immediately after launching a background job.
• The OS handles scheduling, but shells manage job control signals (e.g. SIGTSTP, SIGCONT).
• CPU usage can depend on I/O blocking or whether the process yields control.

Job Control

In Unix-like systems, job control signals allow the shell and users to manage how processes run within a terminal session. These signals enable suspending (SIGTSTP), resuming (SIGCONT), or terminating (SIGINT) jobs. For example, when a user presses Ctrl+Z, the foreground process is sent SIGTSTP, which causes it to pause (or “stop”) execution. The user can then run bg to resume the process in the background, or fg to bring it back to the foreground. Both commands send SIGCONT, which tells the stopped process to continue running.

The shell plays a key role in managing these signals. It tracks process groups and forwards appropriate signals to foreground or background jobs. It also uses system calls like waitpid() to detect when jobs stop or exit, enabling the shell to update job status and provide interactive control. This system enables a single terminal session to juggle multiple processes efficiently and safely.

Common UNIX Job Control Signals

Below is a short example showing how a program might handle SIGTSTP (triggered by Ctrl+Z) using signal() or sigaction():

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

void handle_tstp(int sig) {
    printf("Caught SIGTSTP (Ctrl+Z), ignoring suspend...\n");
}

int main() {
    // Set up custom handler for SIGTSTP
    signal(SIGTSTP, handle_tstp);

    while (1) {
        printf("Running... press Ctrl+Z\n");
        sleep(1);
    }

    return 0;
}

In a real terminal, SIGTSTP normally stops the process regardless of handlers. To truly override this behavior, you need terminal control and job control logic, which is typically managed by the shell. This example only prints a message when the signal is caught (and may not work depending on terminal settings).

Task

Answer the following questions:

1. What is the difference between a foreground and background job in the shell?
2. Who is responsible for scheduling background jobs: the shell or the operating system?
3. Why do background jobs sometimes get stopped when they try to read from the terminal?
4. What role does the shell play in job control, especially in managing job-related signals?

MS-DOS vs FreeBSD: A Process Story

Your teammate Alice is exploring how different operating systems handle program execution for a class project. While reading about legacy systems, she notices that MS-DOS replaces the running program entirely when launching a new one, with no way to resume or manage the previous process. Meanwhile, FreeBSD and other Unix-like systems follow a different approach: they first create a duplicate process with fork(), and then selectively replace it using exec().

This design difference puzzles her. She wonders why modern systems bother with two steps instead of directly loading the new program, and whether the extra complexity actually serves a purpose. To make sense of it, Alice starts comparing how both systems handle multitasking, error handling, and control over the execution flow.

Answer the following questions:

1. What happens when MS-DOS loads a new .exe file? What is lost?
2. In FreeBSD, what are the distinct roles of fork() and exec() during program execution?
3. Compare the flexibility and robustness of these two approaches in multi-tasking environments.

Hints:

• MS-DOS is single-tasking: it replaces the current program in memory.
• FreeBSD allows multi-tasking using process creation (fork) and replacement (exec).
• fork() creates a child process, which can then choose to run a new program using exec().
• The separation allows pre-processing, such as setting up file descriptors or memory mappings before running the new code.
• MS-DOS programs cannot spawn or manage other programs, control returns only when the new program exits.

State of Confusion

While debugging a custom scheduler, you notice that some processes remain stuck in the “Ready” or “Waiting” state far longer than expected. These processes aren’t progressing, some never seem to get scheduled, while others wait indefinitely for events that never occur.

This unexpected behavior raises concerns about possible bugs in the scheduler logic or the way certain blocking operations are handled. To diagnose the issue, it becomes necessary to revisit the expected transitions between process states and explore how processes might become trapped due to scheduling flaws, missed signals, or incorrect assumptions about resource availability.

Answer the following questions:

1. Describe the purpose of the Ready, Running, and Waiting states in a typical process state model.
2. What are valid transitions between these states? What causes them?
3. Why might a process remain in Ready or Waiting indefinitely? Give at least one explanation for each case.

Hints:

• A process in Ready is waiting for CPU time, it is not blocked.
• A process in Waiting is blocked, it’s waiting for some event or I/O to complete.
• The scheduler picks from the Ready queue, not the Waiting list.
• A bug in I/O handling or signaling could cause a process to never exit Waiting.
• A process may starve in the Ready queue if the scheduler is unfair or buggy.

The Phantom Thread

Background

Certainly. Here is the revised background section without hyphens:

Background

In multithreaded Java programs, memory visibility refers to whether one thread’s changes to shared variables become observable by other threads. This issue is governed by the Java Memory Model (JMM), which specifies the rules for how and when reads and writes to variables are propagated between threads and main memory.

By default, the JVM and modern processors may cache variables in registers or processor-local caches. This can lead to a situation where one thread updates a variable, but another thread continues reading a stale value. Such behavior is not a compiler bug. It is legal under the JMM unless a happens before relationship is explicitly established.

Two common ways to enforce visibility are:

• Declaring a variable as volatile, which ensures that reads and writes go directly to main memory rather than being cached
• Using synchronized blocks or methods, which enforce visibility and mutual exclusion by acquiring and releasing locks

Failing to establish proper memory visibility leads to nondeterministic bugs where a thread may never observe an update even though it logically should. These bugs are subtle and often arise in busy wait loops, flags, and concurrent data structures. Understanding and applying the Java Memory Model is essential for writing correct and predictable concurrent programs.

Scenario

You’re reviewing a teammate’s Java program that uses two threads: one sets a shared boolean flag done, while the other loops until the flag becomes true. Despite done = true being executed in the setter thread, the loop sometimes never exits, it gets stuck as if the flag was never set.

Here’s a simplified version of the code:

public class FlagExample {
    static boolean done = false;

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            while (!done) {
                // Busy-wait
            }
            System.out.println("Done!");
        });

        Thread t2 = new Thread(() -> {
            done = true;
        });

        t1.start();
        t2.start();
    }
}

Sometimes, System.out.println("Done!") is printed. Sometimes, it isn’t, even though done = true is always executed.

Answer the following questions:

1. Why does the loop sometimes never terminate even though the flag is set?
2. How does the Java Memory Model explain this behavior?
3. What is the role of the volatile keyword in fixing this bug?
4. Would using synchronized blocks also solve the problem? Why or why not?

Hints:

• Modern CPUs and JVMs may cache variables locally in registers or CPU cache.
• Without proper memory visibility guarantees, threads may not see updates made by others.
• volatile ensures that changes to a variable are visible across threads.
• Busy-wait loops on non-volatile variables are prone to optimization by the compiler or JVM.

static volatile boolean done = false;

The Forgotten Join

You’re helping your teammate to debug a multithreaded C program using POSIX threads. The goal is to create several threads that each perform some logging and then exit. The thread creation appears to work, but sometimes not all log messages are printed, and the program exits unexpectedly early.

Here’s a simplified version of his code:

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

void *log_function(void *arg) {
    int thread_num = *(int *)arg;
    printf("Thread %d is running\n", thread_num);
    sleep(1); // simulate work
    printf("Thread %d has finished\n", thread_num);
    return NULL;
}

int main() {
    pthread_t threads[3];
    int ids[3] = {1, 2, 3};

    for (int i = 0; i < 3; i++) {
        pthread_create(&threads[i], NULL, log_function, &ids[i]);
    }

    // forgot to join threads

    return 0;
}

Sometimes the program prints all thread messages, sometimes it doesn’t. He is unsure whether this is a bug or expected behavior.

Answer the following questions:

1. What happens to a thread created with pthread_create if the main program finishes before it does?
2. What is the purpose of pthread_join, and how does it affect program correctness?
3. Could there be memory-related side effects from omitting pthread_join in this context?
4. Rewrite the loop to properly wait for all threads to complete.

Hints:

• pthread_join(thread_id, NULL) blocks the calling thread until the target thread exits.
• Without joining, the main thread can terminate the entire process prematurely.
• Threads that have not been joined become detached and may leak memory or leave output unfinished.
• Always match pthread_create with pthread_join unless you explicitly detach the thread.

for (int i = 0; i < 3; i++) {
    pthread_join(threads[i], NULL);
}

Stack vs Heap: The Return Trap

In a pthread-based C program, your teammate writes a thread function that returns a pointer to a local character variable. The main thread retrieves this pointer via pthread_join and tries to dereference it. Sometimes it works, but sometimes it results in garbage or even a segmentation fault.

Here’s a simplified version of the code:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void* thread_func(void* arg) {
    char letter = 'X';         // local stack variable
    return (void*)&letter;     // return address of stack variable
}

int main() {
    pthread_t tid;
    char* result;

    pthread_create(&tid, NULL, thread_func, NULL);
    pthread_join(tid, (void**)&result);

    printf("Returned: %c\n", *result); // sometimes garbage, sometimes segfault
    return 0;
}

He wants to know why the behavior is inconsistent, and whether there’s a better way to return values from threads.

Background

In C programs, memory is typically managed using two primary regions: the stack and the heap. These regions serve different purposes and have distinct lifetimes and allocation behaviors.

The stack is used for automatic storage. When a function is called, its local variables are allocated on the stack. This memory is automatically reclaimed when the function returns. In multithreaded programs, each thread receives its own stack. Once a thread terminates, its stack memory is deallocated. Accessing this memory after the thread has exited leads to undefined behavior, such as segmentation faults or stale data. This a common source of dangling pointer bugs.

The heap, by contrast, is a region of memory used for dynamic allocation. Memory allocated on the heap (e.g., via malloc) persists until it is explicitly freed by the program. Heap memory is shared across threads and is not tied to the lifetime of any particular function or thread. This makes it the appropriate choice for returning data from a thread after it has terminated.

Task

Answer the following questions:

1. Why is returning a pointer to a stack variable from a thread unsafe?
2. What happens to the thread’s stack after it exits?
3. How does returning a heap-allocated pointer fix the problem?
4. Rewrite the thread function to correctly return a character pointer.

Hints:

• Stack memory is valid only while the thread is alive.
• After a thread exits, its stack frame is deallocated.
• Heap memory persists beyond the lifetime of the thread that allocated it.
• Always ensure data returned via pthread_join points to valid, live memory.

void* thread_func(void* arg) {
    char* result = malloc(sizeof(char));
    *result = 'X';
    return (void*)result;
}

char* result;
pthread_join(tid, (void**)&result);
printf("Returned: %c\n", *result);
free(result);

Mapping Mayhem: One-to-One or Many-to-Many?

You’re reviewing a performance-critical application that uses a large number of threads to handle concurrent work. It runs fine on your local machine, but performs surprisingly poorly on a production multicore server. CPU usage stays low despite many threads being active.

After profiling, you discover that the thread library in use implements a many-to-one mapping model, where all user threads are managed in user space and mapped onto a single kernel thread. Despite having multiple cores available, the threads do not run in parallel.

Answer the following questions:

1. What are the differences between many-to-one, one-to-one, and many-to-many thread mapping models?
2. Why does a many-to-one model prevent true parallelism on multicore systems?
3. What are the trade-offs between these models in terms of system calls, scalability, and overhead?
4. Which mapping model is most suitable for performance-intensive multithreaded applications on modern systems, and why?

Hints:

• Many-to-one threads are all scheduled by a user-level thread library, not the kernel.
• Only one thread can execute at a time, even on multicore CPUs.
• One-to-one provides true concurrency but incurs system call overhead for every thread.
• Many-to-many offers flexibility, but is harder to implement and less common in mainstream systems.

Fault Isolation

You’re comparing two server implementations: one uses multiple threads, and the other uses multiple processes. Both handle client connections concurrently.

In the threaded version, a bug in one handler causes a buffer overflow and crashes the entire server. In the process-based version, the same bug only crashes a single client handler, the server remains alive and continues serving other clients.

This prompts a deeper investigation into how threads and processes isolate faults differently, and what trade-offs come with each approach.

Answer the following questions:

1. Why does a crash in one thread typically bring down the entire process?
2. How do protection boundaries differ between threads and processes?
3. What are the trade-offs between using threads and processes in terms of fault isolation, performance, and resource overhead?
4. In what scenarios might processes be preferred over threads despite their higher overhead?

Hints:

• Threads share the same address space and memory.
• A fault like a buffer overflow in one thread corrupts the memory of the whole process.
• Processes have separate address spaces, preventing one from corrupting another.
• Context switching between processes is more expensive but offers better isolation.

Heavyweight Messaging

You’re benchmarking two parallel programs that perform the same task: pass one million messages between worker units. One version uses multiple processes, and the other uses multiple threads.

Despite having similar logic, the process-based implementation performs significantly worse. CPU usage is high, but throughput is low. After profiling, you notice that the delays mostly come from inter-process communication and frequent context switching.

You decide to dig into the architectural differences that affect performance.

Answer the following questions:

1. Why is switching between processes more expensive than switching between threads?
2. How do threads achieve faster communication compared to processes?
3. What happens during a process context switch that doesn’t occur with thread switching?
4. How do these differences impact system design choices for parallel workloads?

Hints:

• Thread switching is lighter, no need to flush TLB or change address space.
• Process switching involves MMU updates, cache invalidation, and system calls.
• Threads share memory; processes require IPC mechanisms like pipes or shared memory.
• Thread APIs may run in user space, while process control always involves the kernel.