Runtime & concurrency
Reveal answer and reasoning
An object monitor is owned by the thread that entered it, and that same thread may enter it again with balanced exits. Another thread cannot legally release that monitor. A semaphore instead manages a permit count and does not generally track the acquiring thread or task, so application ownership must be explicit. Reentrant monitor entry therefore does not imply reentrant SemaphoreSlim acquisition or interchangeable release rules.
The lesson uses actual object-typed lock statements and Monitor.IsEntered for a same-thread portable sequence. The external lab separately tests wrong-thread release. A common wrong answer treats every synchronization primitive as a generic lock that any continuation can release. C# rejects await directly in a lock body, and manually spanning an await with Monitor does not solve thread affinity. Also identify the statically selected mechanism: newer dedicated lock types can use compiler-recognized behavior distinct from an object monitor.
What a strong answer covers
- Monitor ownership is thread-affine.
- Reentrant entries still require balanced exits.
- Semaphore permits have a different ownership contract.
Common pitfall
Assuming all synchronization primitives share monitor ownership and reentrancy rules.
Follow-up questions
- Why is manually holding Monitor across await unsafe?
- What changes with a dedicated System.Threading.Lock target?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.