Loadingone moment…
Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
Before adding workers, it is worth knowing what they would buy. Total work divided by worker count is the estimate everybody gives, and it is a lower bound rather than an answer — one long task can dominate a pool of ten.
Write plan_pool(durations, workers). Simulate the pool deterministically and report the schedule. Nothing here starts a thread; the sandbox cannot, and the reasoning is the point.
Function to write
plan_pool(durations: list[int], workers: int) -> dictA dict with the pool's `makespan`, the busy time `per_worker`, and every `assignment`.
How to approach it
Compare the starter's makespan for 5, 3, 8, 2 against the total over two.
Sample cases
+ 2 held back until you submit
four uneven tasks, two workers
Round-robin and next-free-worker disagree here, and the makespan is the proof.
Input
Argument 1
[
5,
3,
8,
2
]Argument 2
2Returns
{
'makespan': 11,
'per_worker': [
7,
11
],
'assignments': [
{
'task': 0,
'worker': 0,
'start': 0,
'end': 5
},
{
'task': 1,
'worker': 1,
'start': 0,
'end': 3
},
{
'task': 2,
'worker': 1,
'start': 3,
'end': 11
},
{
'task': 3,
'worker': 0,
'start': 5,
'end': 7
}
]
}more workers than tasks
Idle workers still appear in the per-worker totals, because a plan has to show the waste.
Input
Argument 1
[
1,
1,
1
]Argument 2
5Returns
{
'makespan': 1,
'per_worker': [
1,
1,
1,
0,
0
],
'assignments': [
{
'task': 0,
'worker': 0,
'start': 0,
'end': 1
},
{
'task': 1,
'worker': 1,
'start': 0,
'end': 1
},
{
'task': 2,
'worker': 2,
'start': 0,
'end': 1
}
]
}nothing to schedule
No tasks means a makespan of zero and no assignments, rather than a division by anything.
Input
Argument 1
[] (empty list)
Argument 2
3Returns
{
'makespan': 0,
'per_worker': [],
'assignments': []
}Constraints
{'makespan': ..., 'per_worker': [...], 'assignments': [...]}.{'task': <index>, 'worker': ..., 'start': ..., 'end': ...}, in the order the tasks were dispatched.per_worker is total busy time per worker, including workers that got nothing.makespan is the largest per-worker total — when the pool finishes.Worked example
Four tasks of 5, 3, 8 and 2 across two workers. Total work is 18, so the naive estimate is a makespan of 9. The real schedule is 11. Worker 0 takes the 5, worker 1 takes the 3 and is free first, so it also takes the 8 — finishing at 11 while worker 0 picks up the 2 and idles from 7. Round-robin does no better and often worse: it would give tasks 0 and 2 to the same worker, for a makespan of 13. The estimate was never wrong about the work; it was wrong about the shape.
What this tests
That parallel speed-up is bounded by the longest task rather than by the total, and that a heap of when-each-worker-is-free is the standard way to reason about a bounded pool without running one.
plan_pool(durations: list[int], workers: int) -> dictSubmit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.