📝 Deadlock Characterization in Operating System (47 MCQs)

📖 From Operating System • 7. Deadlocks • 47 questions available

←Previous Topic:Deadlocks System Model in Operating System📝 Deadlock Characterization in Operating SystemNecessary Conditions for Deadlock Characterization:Next Topic→

What is Deadlock Characterization in Operating System?

Definition:
Deadlock characterization describes the precise conditions under which deadlocks occur, typically categorized by necessary conditions and graphical modeling techniques.

Example:
Characterization involves verifying if Mutual Exclusion, Hold and Wait, No Preemption, and Circular Wait all hold simultaneously for a set of processes $\{P_i\}$ .

Reason:
Accurate characterization provides the theoretical foundation required to distinguish true deadlocks from simple blocking or starvation, enabling correct diagnosis and solution design.

Easy

Medium

Hard

📝 All Deadlock Characterization in Operating System MCQs

Q1. What is a primary consequence of a deadlock in a system?

A.Processes finish executing but release resources late.

B.System resources are tied up, preventing other jobs from starting. ✅

C.The system automatically restarts to resolve the conflict.

D.Resources are freed immediately for other processes.

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: A deadlock results in processes that never complete. Consequently, the resources they hold are never released, which prevents other processes or jobs from acquiring them and starting their own execution. This creates a stall in the system's progress.

Q2. In a deadlock, why are system resources considered to be 'tied up'?

A.Because they are being used efficiently by multiple processes.

B.Because the processes holding them are blocked indefinitely and cannot release them. ✅

C.Because the operating system has reserved them for future use.

D.Because they are physically locked and cannot be accessed.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: 'Tied up' means the resources are allocated but not available for use by other processes. Since the deadlocked processes are waiting for an event that will never occur, they cannot proceed to the 'Release' step, leaving the resources permanently allocated to them.

Q3. What is the ultimate fate of processes that are in a deadlock?

A.They will eventually time out and terminate.

B.They will be swapped out to disk.

C.They never finish executing. ✅

D.They will be given higher priority to break the deadlock.

💡 Difficulty: easy | ✅ Correct: C

📖 Explanation: By definition, a deadlock is a state where processes are waiting indefinitely. They cannot proceed to completion because the resources they need are held by other processes in the same state. Without external intervention, they will never finish executing.

Q4. How does a deadlock affect new jobs in the system?

A.It makes resource allocation faster.

B.It creates more available resources for them.

C.It prevents them from starting due to tied-up resources. ✅

D.It has no effect on new jobs.

💡 Difficulty: medium | ✅ Correct: C

📖 Explanation: If a deadlock holds critical resources, any new job that requires those resources will be unable to acquire them. The new job will either have to wait or fail, effectively being prevented from starting. This blockage can cascade, further degrading system performance.

Q5. The text states that in a deadlock, 'processes never finish executing.' What is the most direct implication of this for the system?

A.The system will become faster over time.

B.System resources will become permanently unavailable. ✅

C.The operating system will automatically terminate the processes.

D.CPU utilization will increase.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: If processes never finish, they never release their held resources. This directly leads to those resources becoming permanently unavailable for allocation. This resource starvation can cause the entire system to halt if critical resources are tied up in a deadlock.

Q6. What is the purpose of the `pthread_mutex_init()` function in a Pthread program?

A.To acquire a mutex lock.

B.To initialize an unlocked mutex. ✅

C.To release a mutex lock.

D.To destroy a mutex lock.

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: The `pthread_mutex_init()` function is used to initialize a mutex lock to a known state, which is unlocked. This must be done before the mutex can be used by threads to synchronize access to shared resources.

Q7. Which Pthread function is used to acquire a mutex lock?

A.pthread_mutex_init()

B.pthread_mutex_lock() ✅

C.pthread_mutex_unlock()

D.pthread_mutex_destroy()

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: The `pthread_mutex_lock()` function is called by a thread to attempt to acquire a mutex lock. If the lock is available, the thread acquires it and continues. If the lock is already held by another thread, the calling thread will block until the lock becomes available.

Q8. In Pthreads, what happens when a thread calls `pthread_mutex_lock()` on a mutex that is already locked by another thread?

A.The call returns an error immediately.

B.The thread is terminated.

C.The calling thread blocks until the mutex is unlocked. ✅

D.The thread is given a higher priority.

💡 Difficulty: medium | ✅ Correct: C

📖 Explanation: The `pthread_mutex_lock()` function is a blocking call. If the mutex is already locked, the thread will be put into a waiting state. It will remain blocked and cannot continue its execution until the mutex owner calls `pthread_mutex_unlock()`, releasing the lock and waking up the waiting thread.

Q9. Which function is responsible for releasing a mutex lock in a Pthread program?

A.pthread_mutex_init()

B.pthread_mutex_lock()

C.pthread_mutex_unlock() ✅

D.pthread_exit()

💡 Difficulty: easy | ✅ Correct: C

📖 Explanation: The `pthread_mutex_unlock()` function is used to release a mutex lock. It should only be called by the thread that currently owns the lock. Releasing the lock allows other threads that are blocked on it to acquire it and proceed.

Q10. If a thread calls `pthread_mutex_lock()` on a mutex that is already locked, what is the state of the calling thread?

A.Running

B.Ready

C.Blocked (Waiting) ✅

D.Terminated

💡 Difficulty: medium | ✅ Correct: C

📖 Explanation: The thread is blocked. It cannot proceed to the 'Running' state because it is waiting for the mutex to become available. It is not 'Terminated' or simply 'Ready' to run; it is specifically waiting on a synchronization primitive, which is a blocked state.

Q11. In the provided code example, what is the first mutex lock that thread one attempts to acquire?

A.second_mutex

B.first_mutex ✅

C.third_mutex

D.mutex_one

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: The code for thread one (`do_work_one()`) explicitly shows `pthread_mutex_lock(&first_mutex);` as the first locking operation. This is the correct sequence according to the provided example.

Q12. In the code example, what is the second mutex lock that thread one attempts to acquire?

A.first_mutex

B.second_mutex ✅

C.mutex_two

D.global_mutex

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: After acquiring `first_mutex`, thread one then calls `pthread_mutex_lock(&second_mutex);`. This establishes the lock order for thread one: first `first_mutex`, then `second_mutex`.

Q13. What is the lock acquisition order for thread two in the provided code example?

A.first_mutex, then second_mutex

B.second_mutex, then first_mutex ✅

C.first_mutex only

D.second_mutex only

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: The code for thread two (`do_work_two()`) shows it first locks `second_mutex` and then `first_mutex`. This lock order is the opposite of thread one's order, which is the cause of the potential deadlock.

Q14. In the Pthread example, what specific sequence of events must occur for a deadlock to happen?

A.Thread one locks second_mutex and thread two locks first_mutex.

B.Thread one locks first_mutex and thread two locks second_mutex. ✅

C.Thread one completes before thread two starts.

D.Thread two completes before thread one starts.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The deadlock condition is triggered when thread one successfully locks `first_mutex` and thread two successfully locks `second_mutex`. At this point, thread one will block waiting for `second_mutex` (held by thread two), and thread two will block waiting for `first_mutex` (held by thread one), creating a circular wait.

Q15. In the provided code example, which scenario would definitely avoid a deadlock?

A.Thread one locks first_mutex and thread two locks second_mutex.

B.Thread one locks second_mutex and thread two locks first_mutex.

C.Thread one acquires and releases both locks before thread two tries to acquire them. ✅

D.Thread one and thread two lock the mutexes in the same order.

💡 Difficulty: hard | ✅ Correct: C

📖 Explanation: A deadlock is avoided if thread one completes its critical section (acquiring both locks, doing work, and releasing them) before thread two begins its locking sequence. This prevents the circular hold-and-wait condition. The order in which they lock is crucial; if they lock in the same order, deadlock is also avoided.

Q16. Even though the Pthread example can result in a deadlock, it is not guaranteed to occur. What factor determines whether the deadlock actually happens?

A.The size of the critical section.

B.The scheduling order of the threads by the CPU scheduler. ✅

C.The number of CPU cores.

D.The priority of the threads.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The deadlock is a race condition. Whether it occurs depends on the timing of the threads' execution, which is determined by the scheduler. If thread one completes its work before thread two starts, no deadlock occurs. The scheduler's decisions create the specific interleaving of thread instructions that can lead to the deadlock.

Q17. Why are deadlocks in multithreaded programs often difficult to identify and test for?

A.The bugs are always visible during normal execution.

B.They may occur only under specific scheduling conditions. ✅

C.They always cause a crash, making them easy to find.

D.They are easily reproducible in a debugger.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: Deadlocks are non-deterministic. They may only manifest when a specific, rare sequence of thread interleavings occurs. This makes them difficult to reproduce during testing, as the same code might run perfectly thousands of times before a particular scheduling pattern triggers the deadlock.

Q18. The text mentions that the order in which threads run depends on the CPU scheduler. What does this imply about the reliability of applications?

A.Applications are always reliable regardless of scheduling.

B.A program may fail only under certain scheduling scenarios, making it unreliable in those cases. ✅

C.The scheduler is guaranteed to prevent deadlocks.

D.The scheduler will always cause deadlocks.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: Because the scheduler's behavior is unpredictable, a deadlock bug might only appear under a specific scheduling order. This means the application is not fully reliable, as its correctness depends on an external and uncontrollable factor (the scheduler's timing). This is a classic 'Heisenbug' scenario.

Q19. What is the fundamental reason that the Pthread example with different lock orders is problematic?

A.It uses two many locks.

B.It creates a possibility of circular wait. ✅

C.It uses mutex locks instead of semaphores.

D.The locks are not initialized properly.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: The different lock orders are the direct cause of the potential circular wait. Thread one holds `first_mutex` and needs `second_mutex`, while thread two holds `second_mutex` and needs `first_mutex`. This cycle is the very definition of a circular wait, which is a necessary condition for a deadlock.

Q20. In the code example, what is the correct sequence of operations for thread one to completely avoid a deadlock with thread two?

A.Lock second_mutex, lock first_mutex, unlock second_mutex, unlock first_mutex.

B.Lock first_mutex, lock second_mutex, unlock second_mutex, unlock first_mutex.

C.Lock first_mutex, unlock first_mutex, lock second_mutex, unlock second_mutex. ✅

D.Lock both mutexes in a single atomic operation.

💡 Difficulty: hard | ✅ Correct: C

📖 Explanation: The only way for thread one to guarantee it will not cause a deadlock with thread two is to ensure it does not hold one mutex while waiting for the other. If it locks and unlocks `first_mutex` before even attempting to lock `second_mutex`, it eliminates the 'hold and wait' condition, making a deadlock impossible in this specific interaction.

Q21. Which of the following best describes the relationship between the two threads in the Pthread example?

A.They both use the same lock order.

B.They use the same mutexes but in opposite orders. ✅

C.They use completely different mutexes.

D.One thread does not use any mutexes.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The key detail is that both threads access both mutexes (`first_mutex` and `second_mutex`). However, thread one locks them in the order (1,2), while thread two locks them in the order (2,1). This inverted order is the source of the potential deadlock.

Q22. If thread one locks `first_mutex` and thread two locks `second_mutex` at the same time, what is the immediate state of thread one?

A.It continues execution after locking second_mutex.

B.It is blocked waiting for second_mutex. ✅

C.It is terminated.

D.It unlocks first_mutex.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: Thread one already holds `first_mutex` and is requesting `second_mutex`. Since `second_mutex` is held by thread two, thread one cannot acquire it. The call to `pthread_mutex_lock(&second_mutex);` will block, putting thread one into a waiting state.

Q23. If thread one locks `first_mutex` and thread two locks `second_mutex` at the same time, what is the immediate state of thread two?

A.It continues execution after locking first_mutex.

B.It is blocked waiting for first_mutex. ✅

C.It is terminated.

D.It unlocks second_mutex.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: Thread two holds `second_mutex` and is requesting `first_mutex`. Since `first_mutex` is held by thread one, thread two cannot acquire it. The call to `pthread_mutex_lock(&first_mutex);` will block, putting thread two into a waiting state.

Q24. In the deadlock scenario of the Pthread example, which mutex does thread one hold?

A.first_mutex ✅

B.second_mutex

C.Both

D.Neither

💡 Difficulty: hard | ✅ Correct: A

📖 Explanation: In the specific deadlock scenario, thread one holds `first_mutex` and is waiting for `second_mutex`. Thread two holds `second_mutex` and is waiting for `first_mutex`. Therefore, thread one holds only `first_mutex` at the moment of deadlock.

Q25. In the deadlock scenario of the Pthread example, which mutex does thread two hold?

A.first_mutex

B.second_mutex ✅

C.Both

D.Neither

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: In the specific deadlock scenario, thread two holds `second_mutex` and is waiting for `first_mutex`. Thread one holds `first_mutex` and is waiting for `second_mutex`. Therefore, thread two holds only `second_mutex` at the moment of deadlock.

Q26. What would happen if both thread one and thread two attempted to lock the mutexes in the same order, for example, first_mutex then second_mutex?

A.A deadlock would be guaranteed.

B.A deadlock would be impossible. ✅

C.The threads would race to lock both mutexes.

D.The program would crash.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: If both threads attempt to acquire the locks in the same order, a deadlock cannot occur. One thread will acquire both locks, do its work, and release them. The other thread will then be able to acquire both locks. There is no scenario where they each hold one lock and wait for the other, because the order prevents the cycle.

Q27. The Pthread example demonstrates that deadlocks can occur even with simple synchronization primitives. What is the underlying cause in this specific example?

A.Using too many mutex locks.

B.A circular wait created by different lock acquisition orders. ✅

C.A bug in the pthread_mutex_lock() function.

D.The threads are not properly initialized.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: The cause is the circular wait. The two threads form a cycle where each is waiting for a resource (mutex) held by the other. This is a direct result of their different lock acquisition orders, which is a common and fundamental cause of deadlocks in multithreaded programming.

Q28. What is the role of the CPU scheduler in the Pthread deadlock example?

A.It actively prevents the deadlock from occurring.

B.It determines the timing of thread execution, which influences if the deadlock occurs. ✅

C.It is irrelevant to the deadlock.

D.It automatically resolves the deadlock by terminating one thread.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The CPU scheduler's decisions on which thread runs and when are the key to whether the deadlock manifests. A specific interleaving of instructions (T1 locks M1, T2 locks M2) is required. The scheduler's behavior, which is non-deterministic from the programmer's perspective, makes these deadlocks hard to test for and reproduce.

Q29. Why is it difficult to identify deadlocks in multithreaded programs like the Pthread example?

A.The code always looks correct, even when it's not.

B.They are often intermittent and depend on runtime scheduling. ✅

C.The compiler provides warnings for all deadlocks.

D.The operating system logs all deadlocks.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: Intermittent bugs are notoriously difficult to identify. A deadlock that only occurs 1% of the time under a specific scheduling scenario is extremely hard to trigger during testing. It may escape detection and only manifest in the field, making it a significant challenge for software quality assurance.

Q30. The text concludes by stating that it is difficult to identify and test for deadlocks that occur only under certain circumstances. This is an example of what type of software bug?

A.A deterministic bug

B.A Heisenbug ✅

C.A Bohrbug

D.A logic error

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: A Heisenbug is a bug that changes its behavior when you try to observe or debug it. More generally, it refers to a bug that is intermittent and occurs under specific, hard-to-reproduce conditions. The deadlock described, which depends on a particular scheduling order, is a classic Heisenbug because it may disappear when you add print statements or run it in a debugger.

Q31. The example with `first_mutex` and `second_mutex` shows a classic deadlock pattern. What is this pattern called when two threads each hold one lock and wait for the other?

A.Resource starvation

B.A race condition

C.Deadly embrace ✅

D.Livelock

💡 Difficulty: hard | ✅ Correct: C

📖 Explanation: 'Deadly embrace' is a classic and descriptive synonym for a deadlock. It specifically describes the scenario where two or more processes each hold a resource needed by the other, creating a circular dependency and effectively embracing each other in a permanent wait. This is the exact situation illustrated in the Pthread example.

Q32. If thread one locks `first_mutex` and then `second_mutex`, and thread two locks `second_mutex` and then `first_mutex`, what is the minimum number of threads required for a deadlock?

A.One

B.Two ✅

C.Three

D.Four

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The deadlock can occur with just these two threads. Thread one holds lock A and needs B, while thread two holds B and needs A. This forms a cycle involving two threads. While deadlocks can involve more threads, two is the minimum number needed to create a circular wait.

Q33. What is the significance of the 'Do some work' section in the Pthread code example?

A.It is the main cause of the deadlock.

B.It represents the critical section where resources are used. ✅

C.It is where the mutexes are initialized.

D.It is where the threads are created.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The 'Do some work' section represents the critical section. This is the region of code where the thread has exclusive access to the shared resources (protected by the mutexes). The deadlock does not occur within this section; it occurs before it, during the lock acquisition phase. The critical section is the reason the locks are needed.

Q34. In the provided code, what is the purpose of calling `pthread_exit(0);` after unlocking the mutexes?

A.It initializes the mutexes.

B.It terminates the thread after it has completed its work. ✅

C.It locks the mutexes again.

D.It creates a new thread.

💡 Difficulty: easy | ✅ Correct: B

📖 Explanation: `pthread_exit(0);` is used to terminate the calling thread. In the context of the code, it is called after the thread has performed its work and released its mutex locks, signaling that the thread has completed its task and can exit.

Q35. The Pthread example uses `NULL` as the second argument to `pthread_mutex_init()`. What does this typically indicate?

A.The mutex is being initialized with default attributes. ✅

B.The mutex is being destroyed.

C.The mutex is being locked.

D.An error has occurred.

💡 Difficulty: medium | ✅ Correct: A

📖 Explanation: In Pthreads, passing `NULL` to the attribute parameter of `pthread_mutex_init()` means the mutex is initialized with the default mutex attributes. This is a common and acceptable practice when no special attributes (like priority inheritance) are required.

Q36. What is the potential consequence if a thread forgets to call `pthread_mutex_unlock()` after its critical section?

A.The system will crash immediately.

B.Other threads waiting for that mutex may be blocked indefinitely. ✅

C.The thread will be terminated.

D.The mutex will automatically unlock after a timeout.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: If a thread does not release a mutex, no other thread can acquire it. Any thread that calls `pthread_mutex_lock()` on that mutex will wait forever (or at least until the thread that holds it is terminated). This is a classic bug that can lead to a deadlock or a resource starvation scenario, effectively halting progress for dependent threads.

Q37. Why are mutex locks considered a 'common source of deadlock' as mentioned earlier in the chapter?

A.They are complex to implement.

B.They are used to protect shared resources, and improper ordering can lead to circular waits. ✅

C.They are always a source of deadlock.

D.They are not a common source of deadlock.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: Mutex locks are used to synchronize access to shared resources. Whenever multiple locks are used, the potential for a deadlock exists if threads acquire them in inconsistent orders. The Pthread example perfectly illustrates this. The need for synchronization creates the conditions for a deadlock, making them a common source of this problem.

Q38. In the Pthread example, if thread one acquires `first_mutex` and is then preempted before it can acquire `second_mutex`, and thread two acquires `second_mutex`, what is the state of the system?

A.A deadlock has occurred.

B.The system is operating normally.

C.A deadlock is imminent but has not yet occurred. ✅

D.The system has resolved the deadlock.

💡 Difficulty: medium | ✅ Correct: C

📖 Explanation: The system is on the verge of a deadlock. Thread one holds `first_mutex` and thread two holds `second_mutex`. The deadlock will complete when thread one requests `second_mutex` and thread two requests `first_mutex`. However, if one of them releases its mutex before the next lock request, the deadlock is avoided. The current state is a pre-deadlock condition.

Q39. What is the role of the `&` (address-of) operator in the calls to `pthread_mutex_lock()` and `pthread_mutex_unlock()` in the code?

A.It passes the mutex by value.

B.It passes a pointer to the mutex. ✅

C.It is a syntax error.

D.It performs a bitwise AND operation.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: In C, the `&` operator is used to get the memory address of a variable. The Pthread functions like `pthread_mutex_lock()` expect a pointer to a mutex object. Therefore, `&first_mutex` provides the address of the `first_mutex` variable, allowing the function to operate on that specific mutex.

Q40. The text mentions that deadlocks are difficult to identify and test for. What is the most effective way to prevent this specific type of deadlock in the Pthread example?

A.Use only one mutex lock.

B.Ensure all threads acquire mutex locks in the same global order. ✅

C.Increase the priority of one thread.

D.Use semaphores instead of mutex locks.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: The most straightforward and effective prevention for this type of deadlock is to enforce a strict, global ordering for lock acquisition. If every thread in the system always locks `first_mutex` before `second_mutex`, the circular wait condition can never be met. This is a fundamental principle of deadlock prevention.

Q41. If thread one acquires and releases both mutexes, and thread two does the same, but they are executed sequentially (one after the other), will a deadlock occur?

A.Yes, a deadlock is guaranteed.

B.No, a deadlock will not occur. ✅

C.It depends on the number of CPU cores.

D.It depends on the priority of the threads.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: If the threads run sequentially, there is no interleaving. Thread one will complete its entire lock-work-unlock sequence before thread two starts. Since thread one releases the locks, thread two will always find them available. Without the possibility of the threads holding locks simultaneously and waiting for each other, a deadlock cannot occur.

Q42. The code example uses `pthread_mutex_t` to declare mutexes. What does the `_t` suffix typically indicate in POSIX (e.g., `pthread_t`, `size_t`)?

A.That the type is a thread-safe variable.

B.That the type is a typedef (type definition). ✅

C.That the type is a temporary variable.

D.That the type is a pointer.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: In POSIX and C programming conventions, `_t` is a common suffix for typedefs. These are aliases for specific data types. `pthread_mutex_t` is a typedef for the mutex data structure, providing an abstraction for the mutex object rather than exposing its internal structure.

Q43. In the deadlock scenario, thread one is blocked on `pthread_mutex_lock(&second_mutex);`. What is the state of its already acquired `first_mutex`?

A.It is released automatically.

B.It is still held by thread one. ✅

C.It is released to prevent deadlock.

D.It is transferred to thread two.

💡 Difficulty: hard | ✅ Correct: B

📖 Explanation: The thread will not release a mutex it already holds just because it is blocked. It continues to hold `first_mutex` while it waits for `second_mutex`. This is the 'hold and wait' condition, which is a necessary condition for a deadlock to occur. The mutex is only released when the thread explicitly calls `pthread_mutex_unlock(&first_mutex);`.

Q44. What is the relationship between the `pthread_mutex_init()` function and the mutex variables declared in the code?

A.init() creates the variables.

B.init() initializes the variables, preparing them for use. ✅

C.init() is used to lock the variables.

D.init() is used to destroy the variables.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: The `pthread_mutex_t` variables declare the existence of the mutex locks. However, they are not in a valid state for use until `pthread_mutex_init()` is called on them. The `init()` function initializes the internal state of the mutex, making it ready to be locked and unlocked.

Q45. If a third thread is added to the Pthread example that locks and unlocks the mutexes in a random order, how would this affect the system?

A.It would eliminate the deadlock.

B.It would guarantee a deadlock.

C.It would increase the complexity and potentially create more deadlock scenarios. ✅

D.It would have no effect.

💡 Difficulty: hard | ✅ Correct: C

📖 Explanation: Adding more threads and more complex locking patterns would likely increase the system's complexity. It would create more possible lock interleavings and could introduce new or more frequent deadlocks. In general, more complex concurrency makes deadlocks more difficult to analyze and prevent, not easier.

Q46. What is the final action performed by thread one in the `do_work_one()` function before calling `pthread_exit(0)`?

A.It locks first_mutex.

B.It unlocks first_mutex. ✅

C.It locks second_mutex.

D.It unlocks second_mutex.

💡 Difficulty: medium | ✅ Correct: B

📖 Explanation: Following the principle of releasing resources in the reverse order of acquisition (or simply ensuring all held locks are released), thread one's code shows the last unlock operation is `pthread_mutex_unlock(&first_mutex);`. This makes sense as it was the first lock acquired.

Q47. The Pthread example is designed to show a potential deadlock. What specific condition does it NOT require to occur?

A.The threads must run on different CPU cores. ✅

B.The threads must be multithreaded.

C.Mutual exclusion (provided by the mutexes).

D.The threads must hold resources while waiting for others.

💡 Difficulty: hard | ✅ Correct: A

📖 Explanation: The deadlock can occur even on a single-core CPU, as it is a result of scheduling and thread interleaving, not parallel execution. The core conditions for a deadlock (mutual exclusion, hold and wait, no preemption, circular wait) are all present, but running on different cores is not a requirement for a deadlock to occur.

🔗 Related Topics (MCQs)

📝 Deadlocks Introduction in Operating System MCQs 📝 Deadlocks System Model in Operating System MCQs 📝 Necessary Conditions for Deadlock Characterization MCQs 📝 Methods for Handling Deadlocks in Operating System MCQs 📝 Mutual Exclusion Deadlock Prevention MCQs

←Previous Topic:Deadlocks System Model in Operating System📝 Deadlock Characterization in Operating SystemNecessary Conditions for Deadlock Characterization:Next Topic→