Runtime & concurrency
Reveal answer and reasoning
TryPeek is an observation that does not remove or claim an item. Another consumer can change the queue before the caller performs a later operation. TryDequeue is the operation that attempts ownership transfer, and its success boolean must be retained with its out value. Thread safety for each operation does not combine a peek, count check, and removal into one atomic workflow.
The lesson's desktop barrier makes both consumers see the same head before they remove two different values. A common wrong answer assumes FIFO means the first peeking worker owns that item or that a nonempty Count guarantees a later removal succeeds. Processing success and durable acknowledgment are further boundaries after removal. ConcurrentQueue supplies neither automatic retry nor broker delivery guarantees, so consumer code must define what it does with an actually claimed item when later work fails.
What a strong answer covers
- Peek observes without claiming.
- TryDequeue success determines removal ownership.
- FIFO item order differs from worker fairness and acknowledgment.
Common pitfall
Treating a prior peek or nonempty observation as exclusive ownership of a later removal.
Follow-up questions
- Why is Count not a reservation?
- What happens if processing fails after removal?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.