liveBook · Manning

Unsafe state

As explained in Learn Concurrent Programming with Go

An unsafe state is a resource-allocation state for which no schedule is guaranteed to let all executions complete within their maximum resource demands.

An unsafe state is a resource-allocation state with no guaranteed schedule that lets every execution complete, even when each requests its maximum resources. section 11.2.2

The Banker's algorithm grants a request only when the resulting allocation remains safe; otherwise, it suspends the requesting execution until granting the request becomes safe. section 11.2.2

Database connection pool

With a fixed pool, granting execution a another session can leave too few resources for executions a, b, and c to reach their maximum demands. The allocation becomes unsafe because no completion schedule remains guaranteed, creating an unavoidable risk of deadlock. section 11.2.2

Figure 11.10 Examples of safe and unsafe state scenarios

Compare safe and unsafe resource allocations and see how one additional grant can remove every guaranteed completion schedule. section 11.2.2

How Learn Concurrent Programming with Go covers it

How deep it goes
Defines safety through guaranteed completion schedules and stops short of deriving the Banker's algorithm step by step.
Examples
Illustrates unsafe allocation with a fixed database connection pool and contrasting safe and unsafe scenarios.
What it assumes
Assumes resource limits, current allocations, maximum demands, and available resources are known.
What you can do after
Evaluate whether granting a resource request preserves a schedule in which all executions can complete.
How it connects
Connects resource allocation with deadlock, the Banker's algorithm, maximum resource demands, and scheduling.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Learn Concurrent Programming with Go. The section links point to the parts of the book it draws on.