Loading...
Tasks can overlap only where their dependencies permit it. Follow a concrete interleaving to see why concurrent progress can improve responsiveness and also create inconsistent shared state.
What you'll be able to do
Concurrency means tasks make overlapping progress; it can be scheduled on one processor through time sharing. Parallelism means work actually executes at the same time on separate resources. A program can be concurrent without being parallel. Multiple cores provide an opportunity for parallel work only if the program and workload can use them.
For a report, loading two independent source files can overlap. Combining their totals must wait until both loads and validations finish. A dependency graph helps identify the barrier. If one operation needs another’s output, starting them together without coordination does not remove that dependency; it introduces a possible use of incomplete or stale data.
Suppose count starts at zero and two tasks each perform count=count+1. At a lower level this can involve reading count, calculating a new value and writing it. Both tasks can read zero before either writes, then both write one. The final value is one even though two increments were intended.
A critical section protected by a suitable lock can make the related read and write act as one coordinated operation relative to competing tasks. Alternatively a system may provide an appropriate atomic increment. Locking only the write while leaving the read outside does not necessarily protect the whole decision. Use the execution model given; a source-code line is not universally an indivisible operation.
Concurrent work can improve response while waiting for I/O and increase throughput on suitable parallel hardware. Communication, synchronisation, memory pressure and uneven work distribution add costs. A shared database or storage device can remain the bottleneck even after computation is divided across many workers. Measure the complete operation, including joining results.
Deadlock can occur when tasks hold resources while waiting for one another. For example, task A holds lock X and waits for Y, while task B holds Y and waits for X. A consistent global lock acquisition order can prevent that particular circular wait. Timeouts and recovery policies may also matter. More locks do not automatically mean a safer or faster design.
| Step | Task A | Task B | Shared count |
|---|---|---|---|
| 1 | Read 0 | — | 0 |
| 2 | — | Read 0 | 0 |
| 3 | Calculate 1 | — | 0 |
| 4 | — | Calculate 1 | 0 |
| 5 | Write 1 | — | 1 |
| 6 | — | Write 1 | 1 |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.