Concurrency: Client-Server Model
Structure client-server concurrent systems to isolate shared state and avoid subtle threading bugs.
Separate Concurrency from Logic
A server that handles HTTP requests is a concurrency concern. The business logic that processes each request is a separate concern. Mixing them creates untestable code. Extract the business logic into pure, single-threaded functions — easy to unit test, easy to reason about.
Limit Scope of Shared Data
The more threads share the same data, the higher the risk of race conditions. Keep shared data to a minimum. When sharing is unavoidable, use the smallest possible critical section. Prefer immutable data — data that cannot be changed cannot have a race condition.
Code Challenge
Fix the unprotected shared state in the server handler.
💡Key takeaway
Concurrency and business logic are separate concerns. Keep them in separate classes; test the logic without threads.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: Separate server threading concerns from business logic. Keep the scope of shared data as narrow as possible.
✗ Your version