Why is it dangerous to hold a lock or synchronization resource while awaiting asynchronous work?

await _gate.WaitAsync(ct);
try
{
    // Keep this section small: update local state only.
    _inFlight.Add(command.Id);
}
finally
{
    _gate.Release();
}

await _externalClient.SendAsync(command, ct);

The external call happens outside the protected section so one slow dependency does not block local coordination.

• Performing HTTP or database calls while holding synchronization.
• Forgetting release in finally.
• Using in-memory synchronization for distributed workflow correctness.
• Creating nested locks with inconsistent ordering.
• Not measuring time spent waiting for locks or semaphores.

A weak answer says 'use lock to make it safe' without discussing lock scope. Senior answers focus on minimizing protected work and avoiding I/O inside coordination.

• Why is await not allowed inside a lock block?
• How would you measure lock contention?
• When should a database constraint replace a lock?
• What happens if the external call times out while holding a semaphore?

Look for critical-section design and production impact. Senior candidates connect synchronization to latency, failure amplification, and ownership boundaries.

This checks whether the candidate can reason about concurrency beyond syntax and avoid common production stalls.