This trace follows the actual state transitions behind the companion Processes, Threads, and the Cost of Sharing. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Place work in runnable state
A process is a protected resource container with an address space and operating-system-managed resources. A thread is an execution stream with its own program counter, registers, and stack. Threads in one process normally share code and heap memory, which makes communication cheap but coordination necessary.
Step 2: Select a thread to run
When a thread blocks on I/O, the scheduler may run another runnable thread. A context switch saves enough state to resume later and changes which execution stream receives CPU time. Creating a thread does not guarantee it runs immediately; scheduling policy, contention, and available cores influence when it progresses.
Step 3: Save and restore context
When a running thread blocks, the scheduler can run another eligible thread; threads in one process share address space, so they must coordinate updates to shared invariants.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Block or wake on an event
Threads share mutable state, so unsynchronized access can produce races even on a single core through interleaving. Processes provide stronger isolation but require explicit communication and often more setup. More threads can increase context switching, memory use, and contention instead of increasing throughput.
Step 5: Coordinate shared memory
A server creates one thread per connection and suddenly slows down under a large idle-client load. Name two resource costs and one alternative concurrency model to evaluate.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.