Runtime & concurrency
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Reflection;
using System.Linq.Expressions;
using System.Threading;
using System.Threading.Tasks;
var queue = new Queue<int>();
Console.WriteLine($"ready-before:{queue.Count != 0}");
queue.Enqueue(7);
int value = queue.Count != 0 ? queue.Dequeue() : throw new InvalidOperationException();
Console.WriteLine($"value:{value}");
Console.WriteLine($"ready-after:{queue.Count != 0}");
Reveal answer and reasoning
The output is ready-before:False, value:7, and ready-after:False. The ordinary queue starts empty, then receives seven. The guarded sequential removal returns seven and leaves the queue empty again. There are no Monitor.Wait or Pulse calls and no worker threads in this snippet. Its results are direct state observations used to explain the predicate the external protocol later protects.
The common wrong trace invents a blocked waiter, notification loss, or scheduler order from the surrounding lesson topic. Those behaviors are not executed by this code. The actual desktop lab has its own real monitor and bounded consumers and reports value seven with zero remaining after joins. Keeping those scopes separate is essential: the portable program proves its local queue transition, while condition-variable correctness also needs monitor ownership, shared-state discipline, completion, and deadline behavior that a sequential queue cannot establish.
What a strong answer covers
- The queue is empty, contains seven, then is empty.
- The companion performs no monitor waiting.
- Actual OS-thread evidence belongs to the external lab.
Common pitfall
Claiming a sequential predicate companion executed a real condition-variable or scheduler protocol.
Follow-up questions
- What happens if the queue is prefilled before the check?
- What would two enqueued values leave after one removal?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.