Create a bounded Go worker-pool example that processes four jobs and collects every result without depending on completion order.
Four synthetic jobs contain values 2, 3, 4 and 5. Two workers square each value. Completion order is unspecified; the final report sorts by job ID. Each submitted job must produce exactly one result.
| Job ID | Input | Expected square |
|---|---|---|
| 1 | 2 | 4 |
| 2 | 3 | 9 |
| 3 | 4 | 16 |
| 4 | 5 | 25 |
Start with a sequential function that maps one job to one result. Keep the transformation deterministic so concurrency can be tested against a simple baseline. Use a struct with an ID instead of relying on slice position after results arrive. The case does no external work and has no sensitive input.
Write job and result types plus the square function.
Sequential baseline
Record your result and evidence here or in a separate file.
The four expected values are 4, 9, 16 and 25.
Verify the sequential result before introducing goroutines.
A fixed number of workers limits simultaneous processing. Workers read jobs until the jobs channel is closed. The producer closes that channel after sending every job. Avoid creating a goroutine for every unbounded input without considering resource use; this exercise intentionally uses exactly two workers.
Implement two workers consuming a jobs channel.
Worker-pool source
Record your result and evidence here or in a separate file.
Every job is submitted once and processed once.
Track job IDs rather than counting log messages.
Use a wait group to know when all workers have finished sending results. A separate coordinator closes the results channel only then. Closing it from an individual worker can make another worker send to a closed channel. Collect results concurrently so a small channel buffer does not cause a deadlock.
Add completion coordination and range over the result channel.
Completion-safe collector
Record your result and evidence here or in a separate file.
Collection terminates after all four results without an arbitrary sleep.
Use synchronization rather than a guessed waiting time.
Compare results by ID, not arrival order. Check for missing and duplicate IDs as well as correct values. A race detector can help inspect a real run, but it is not available here because the preparation environment lacks Go. The package includes source and local commands without claiming they executed.
Run go test and the race check locally when available.
Concurrency test record
Record your result and evidence here or in a separate file.
All four IDs appear once; ordering differences do not fail a valid run.
Sort or map results before comparison.
A finite fixture can finish without cancellation, but a real service needs timeouts, cancellation and error handling. State those gaps rather than adding an untested production wrapper. Explain channel ownership and what would need to change for slow or failing jobs. The example is educational and does not promise throughput gains.
Write a channel-ownership diagram and an extension plan.
Go handoff
Record your result and evidence here or in a separate file.
The README identifies producer, workers and results closer.
Name one owner for each close operation.
Deliver the sequential baseline, worker pool, result checks and channel-ownership explanation. Add an empty-job case and demonstrate clean termination in a local Go environment.
No worker closes the shared results channel prematurely and every job ID has exactly one result.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The result set is {1:4, 2:9, 3:16, 4:25}; its value sum is 54. Arrival order may vary. The source uses two workers and a completion coordinator. Go compilation, runtime and race-detector checks were not performed in the preparation environment.
This is a finite local concurrency example, not a resilient task queue or a benchmarked service.