Thinking concurrently — OCR A-Level Computer Science
Thinking concurrently explained
Thinking concurrently covers 2 specification points, including (a) Determine the parts of a problem that can… and (b) Outline the benefits and trade offs that….
Read the full explanation
Open a point below for its explanation and revision guidance.
(a) Determine the parts of a problem that can be tackled at the same time.
This criterion asks you to determine which parts of a problem are independent, so they can be tackled at the same time. First break the problem into sub-tasks, then test each pair for dependency: a task is blocked if it needs another task's unfinished result. Sub-tasks that read data and write results without relying on each other are candidates for concurrent execution. For example, finding the total and the largest value of a list can run together, since neither needs the other's output. Calculating a mean is different because the division needs both the total and the count. Shared data changed by two parts at once must be protected, or results may conflict.
(b) Outline the benefits and trade offs that might result from concurrent processing in a particular situation.
Concurrent processing lets several tasks progress over the same period, often by interleaving on one processor. To outline its benefits and trade offs, first fix a particular situation, such as an online ticket booking system serving many customers. Benefits might include better responsiveness, since one task can run while another waits for input or a disk read, and higher overall throughput. Trade offs might include extra complexity, the need to synchronise shared data to avoid race conditions, a risk of deadlock, and switching overhead. Keep the outline brief: name each point, link it to your chosen situation, and note that outcomes depend on design rather than being guaranteed.
Your focus
- Decompose a given problem into sub-tasks with stated inputs and outputs.
- Identify pairs of sub-tasks that are independent and pairs that depend on each other.
- Justify which sub-tasks can run concurrently and which must be sequenced.
Show all 6 objectives
- Describe concurrent processing for a named situation.
- Outline at least one benefit and one trade off of concurrency in that situation.
- Explain why a benefit or trade off depends on the design of the system.
Thinking concurrently exam tips
Marking Points
- Identifies sub-tasks that do not need another sub-task's output.
- Tests each pair of sub-tasks for dependency before deciding that they can run together.
- Explains why a task that uses an unfinished result must wait for that result.
- Recognises that tasks reading or changing shared data need protection when both run at once.
- Describes concurrent processing as several tasks making progress over the same period, not necessarily at the same instant.
- Explains at least one benefit, such as improved responsiveness or throughput, and links it to the chosen situation.
- Names at least one trade off, such as extra complexity or synchronisation effort, and links it to the same situation.
- Uses hedged wording such as might or can to show that benefits and trade offs depend on the design.
- Keeps the outline brief, setting out the key points rather than developing a full extended argument.
Examiner Tips
- 💡List each sub-task and write beside it its inputs and outputs before comparing them.
- 💡Look for words such as needs, uses or waits for, which signal a dependency.
- 💡Check that each option keeps every dependent pair in a sequence rather than in the same concurrent group.
- 💡Name a specific situation, such as a booking system, a game server or a web server, and refer back to it in each point.
- 💡Give one benefit and one trade off in turn so that the answer covers both parts of the statement.
- 💡Keep each point to a sentence or two, because outline asks for main features rather than a detailed discussion.
Common Mistakes
- Treats any two sub-tasks as independent without checking the data flow; check whether one needs the other's output.
- Places a dependent calculation, such as a mean that needs the total, in the concurrent group; sequence it after the tasks it depends on.
- Overlooks a shared variable that two concurrent tasks both update; identify the shared data and control access to it.
- Lists benefits without linking them to the particular situation; correct by naming the situation and explaining how each benefit applies to it.
- Treats concurrency as always faster; correct by stating that coordination and switching overheads can reduce or cancel any speed gain.
- Confuses concurrency with parallelism by assuming tasks always run at the same instant; correct by noting that concurrent tasks may interleave on one processor.
- Presents trade offs as certain outcomes; correct by using hedged language such as might or can.