In a multi-threaded Linux process, Thread1 and Thread2 each have their own private call...
IBM technical mcq question, verified with a worked answer. Free to practise - no sign-up.
In a multi-threaded Linux process, Thread1 and Thread2 each have their own private call stack but share the same global data segment and address space. Both threads are executing the same function concurrently and attempting to modify a global variable without synchronization mechanisms (e.g., mutexes). What will happen?
Show answer & explanation
Without synchronization primitives, concurrent access to a shared global variable creates a race condition. The CPU scheduler can interleave thread execution in arbitrary ways, causing interleaved read-modify-write operations that produce non-deterministic results. While each thread has its own stack for local variables, global variables reside in the shared data segment and are accessible to all threads, making unsynchronized modifications inherently unsafe.
Step-by-step Derivation:
Step-by-step analysis:
- Thread1 reads global_var (value = X)
- Context switch to Thread2
- Thread2 reads global_var (value = X)
- Thread2 modifies and writes (value = Y)
- Context switch back to Thread1
- Thread1 modifies its cached value and writes (value = Z)
- Final result: Z (Thread2's write is lost). But due to scheduler non-determinism, any ordering is possible.
Why other options are wrong:
- (A) Assumes deterministic ordering; scheduler behavior is non-deterministic.
- (B) Confuses stack (private per thread) with global data (shared); global modifications are NOT isolated.
- (D) False; without explicit synchronization, no automatic protection exists in user-space code.