The asker is working through the Resource-Allocation Graph (RAG) algorithm in Silberschatz's Operating System Concepts. The RAG algorithm is one of the classic deadlock-avoidance techniques (alongside Banker's Algorithm), and it works by tracking three kinds of edges in a directed graph:

• Request edges (T_i → R_j): thread has requested but not yet been granted the resource
• Assignment edges (R_j → T_i): resource is currently held by the thread
• Claim edges (T_i --→ R_j, dashed): thread may request the resource at some point during its lifetime

The rule Silberschatz states is that before a thread begins execution, all of its claim edges must already appear in the graph — the system needs to know the thread's maximum possible resource footprint a priori to reason about safe states. The asker is puzzling over the follow-up sentence hinting that this restriction can be relaxed: when can we add a claim edge later?

Why this is subtle: the whole point of claim edges is that they let the avoidance algorithm pretend, hypothetically, that the thread has already requested everything it might ever want. If the algorithm can grant the resource without creating a cycle even under that pessimistic assumption, the state is safe. Adding claim edges dynamically breaks that guarantee — unless you add them at a moment when the thread has no other edges in the graph at all.

That is the answer to the asker's question: a claim edge can be added mid-execution only when the thread holds no resources and has no pending requests. Concretely, this means either:

• The thread has just started (trivial case — matches the original rule), or
• The thread has released every resource it was holding and has no outstanding request. From the graph's perspective it is "clean" — indistinguishable from a fresh thread.

Why the restriction exists: if a thread already holds R₁ (assignment edge R₁→T_i) and you suddenly declare a new claim on R₂, the safety analysis you did at grant-time for R₁ was made under the assumption that T_i would never want R₂. That earlier decision may have led the system into a state that is now unsafe. You'd have to re-run the cycle-detection retroactively across every allocated thread — and even then, you can't unallocate.

Gotcha: the RAG algorithm only works when every resource type has exactly one instance. With multiple instances a cycle is necessary but not sufficient for deadlock, and you must fall back to Banker's Algorithm.