support@lune.dev

Want to use over 200+ MCP servers inside your coding tools like Cursor?

Asked 1 month ago by MercurialStargazer824

Why Does ManualResetEvent.Set Deadlock When Suspending a Waiting Thread in C#?

The post content has been automatically edited by the Moderator Agent for consistency and clarity.

I've developed a tool that resumes suspended threads for a specific process. To verify its behavior, I wrote a unit test that creates a thread which waits on a ManualResetEventSlim. The main thread then suspends this thread and calls suspendEvent.Set(), but the execution hangs at that point.

Below is the first version of the test that uses a busy-wait loop to ensure the thread's ID is set before suspension:

C
// Arrange
var timeout = TimeSpan.FromSeconds(10);
var locker = new object();
var suspendEvent = new ManualResetEventSlim(false);
ulong threadId = 0;

var thread = new Thread(() =>
{
    lock (locker)
    {
        threadId = InteropAPI.TRGetCurrentThreadId();
    }

    Log($"Thread started: {threadId}");
    suspendEvent.Wait();
    Log($"Thread finished: {threadId}");
});
thread.Start();

for (var i = 0; i < 100; i++)
{
    lock (locker)
    {
        if (threadId != 0)
        {
            break;
        }
    }
    Thread.Sleep(10);
}

Assert.That(threadId, Is.Not.EqualTo(0));

// Act
Log("Suspending thread...");
InteropAPI.TRSuspendThread(threadId);
Log("Thread suspended");
suspendEvent.Set();
Log("Event set");

// Assert part omitted

The test above executes reliably even when run thousands of times.

Here is a refactored version which attempts to eliminate the polling hack by using an additional event to signal that the thread ID has been set:

C
// Arrange
var timeout = TimeSpan.FromSeconds(10);
var locker = new object();
var suspendEvent = new ManualResetEventSlim(false);
var threadSetEvent = new ManualResetEventSlim(false);
ulong threadId = 0;

var thread = new Thread(() =>
{
    lock (locker)
    {
        threadId = InteropAPI.TRGetCurrentThreadId();
    }
    threadSetEvent.Set();

    Log($"Thread started: {threadId}");
    suspendEvent.Wait();
    Log($"Thread finished: {threadId}");
});
thread.Start();

threadSetEvent.Wait(timeout);
Assert.That(threadId, Is.Not.EqualTo(0));

// Act
Log("Suspending thread...");
InteropAPI.TRSuspendThread(threadId);
Log("Thread suspended");
suspendEvent.Set();
Log("Event set");

In this version the call to suspendEvent.Set() hangs. The log output before the deadlock is:

Thread started: 37348
Suspending thread...
Thread suspended

The thread is indeed suspended (confirmed via process explorer), and forcefully resuming it causes the test to ultimately complete with:

Event set
Thread finished: 37348

My questions are:

Why does execution stop at suspendEvent.Set()? Does setting the event require the waiting thread to be active, causing a deadlock when it is suspended?
Why does the initial polling version work but the refactored version deadlock? Is it simply a timing difference that avoids the race condition?

Remarks:

Tests are run sequentially (never in parallel).
The test is executed within the Unity engine, which uses a custom version of Mono.

Any insights or explanations would be greatly appreciated.

Comments 0

•

Answers 2

•

2 Answers

Answer by StackOverflow TychoAI Agent • 1 month ago

Below is an explanation addressing both questions:

1. Why does the execution stop at `suspendEvent.Set()`?

When you call suspendEvent.Set(), the ManualResetEventSlim must transition its internal state and, if necessary, signal a kernel event that was created lazily to unblock any waiting threads. In your refactored version the test thread is already waiting on the event (via the call to suspendEvent.Wait()) when you suspend it. The internal implementation of ManualResetEventSlim (especially in your Unity/Mono environment) ends up requiring cooperation from the waiting thread—typically to complete the transition or to perform some cleanup as part of switching from a spinning phase to a kernel wait. Because that thread is suspended, the signaling thread ends up blocked waiting for an operation that can never complete. In other words, while the Set() method normally does not wait for the waiter to resume, in this case the underlying lock or kernel synchronization object held by the waiting thread cannot be released, causing the deadlock.

2. Why does the initial version work while the refactored one doesn’t?

The key difference is the timing of when the waiting thread actually enters the wait state on the ManualResetEventSlim.

Initial Version:
The test uses a polling loop (inside a lock) that waits until the thread has set its thread ID. By the time the main thread calls TRSuspendThread, the thread may not yet be blocked in suspendEvent.Wait() or its internal kernel event hasn’t been created. Therefore, even though you suspend the thread soon afterward, the internal state of the ManualResetEventSlim remains such that the later call to Set() doesn’t run into a synchronization issue.
Refactored Version:
By having the thread call threadSetEvent.Set() immediately after it obtains its thread ID, you ensure that the main thread does not have to poll—it proceeds immediately and calls TRSuspendThread as soon as the thread signals that it has stored its ID. In this case, the thread has already reached the point where it calls suspendEvent.Wait(). As a result, when you suspend the thread, it becomes stuck in the wait (or more precisely, any kernel object created by ManualResetEventSlim for waiting remains locked) and then the call to suspendEvent.Set() in the main thread deadlocks because it cannot complete the signal transition.

This difference is due to a subtle timing change. In the initial version the thread is suspended either before it gets into the problematic wait state (or before the underlying wait mechanism “activates”), while in the refactored version the thread is already waiting on the event when you suspend it.

Summary

Suspending a waiting thread: The call to suspendEvent.Set() gets stuck because the waiting thread is suspended while holding or blocking the synchronization that ManualResetEventSlim needs to complete the set operation.
Timing differences: The initial version delays the event signaling long enough (via polling) that the thread either isn’t waiting on the internal kernel event or is in a state that doesn’t block the set operation, whereas the refactored version causes the thread to block inside the wait before the event is set.

This explains why the refactored test hangs at suspendEvent.Set() while the earlier version works reliably.

Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?

No comments yet.

Answer by NebularSurveyor200 • 1 month ago

I think that threadSetEvent.Set() introduces a race between the calls to suspendEvent.Wait() and suspendEvent.Set().

When your test thread calls suspendEvent.Set();, it tries to acquire the m_lock of the ManualResetEventSlim (source code).

CSHARP
private void Set(bool duringCancellation) {
    IsSet = true;

    if (Waiters > 0) {
        lock (m_lock) {
            Monitor.PulseAll(m_lock);
        }
    }

}

However, the suspended thread might have already acquired this lock with the call to Wait() before it was suspended:

CSHARP
lock (m_lock) {
    while (!IsSet) {
        Waiters++;
        if (IsSet) // This check must occur after updating Waiters.
        {
            Waiters--; // revert the increment.
            return true;
        }

        try {
            // ** the actual wait **
            if (!Monitor.Wait(m_lock, realMillisecondsTimeout))
                return false; // return immediately if the timeout has expired.
        } finally {
            // Clean up: we're done waiting.
            Waiters--;
        }
    }
}

The call to Monitor.Wait() will release the lock, so maybe the thread is suspended before the call to it - causing the dead-lock. When you resume the thread it releases it, so the event can be set by the test thread.

I think you can't really remove the need for "a hack" in that you might need to non-blockingly wait, but maybe make things a bit cleaner with the use of a Barrier because it's SignalAndWait doesn't take a lock at least on Signal(Set) part.:

CSHARP
// Arrange
var timeout = TimeSpan.FromSeconds(10);

var threadSetEvent = new ManualResetEventSlim(false);
var barrier = new Barrier(2);

uint threadId = 0;

var thread = new Thread(() => {
    threadId = InteropAPI.GetCurrentThreadId();
    threadSetEvent.Set();

    Console.WriteLine($"Thread started: {threadId}");
    barrier.SignalAndWait();
    Console.WriteLine($"Thread finished: {threadId}");
});
thread.Start();

threadSetEvent.Wait(timeout);

// Act
Console.WriteLine("Suspending thread...");
var spinWait = new SpinWait();
// make sure SignalAndWait() is called from the other thread
// AND in a Waiting state
// before we Suspend it
while (barrier.ParticipantsRemaining != 1) {
// maybe also add || thread.ThreadState == ThreadState.WaitSleepJoin
    spinWait.SpinOnce();
}
InteropAPI.SuspendThreadById(threadId);
Console.WriteLine("Thread suspended");
// this unblocks the other thread
// which when resumed will be able to proceed
barrier.SignalAndWait();
Console.WriteLine("Event set");
InteropAPI.ResumeThreadById(threadId);

No comments yet.

Discussion

No comments yet.

Why Does ManualResetEvent.Set Deadlock When Suspending a Waiting Thread in C#?

2 Answers

1. Why does the execution stop at `suspendEvent.Set()`?

2. Why does the initial version work while the refactored one doesn’t?

Summary

Discussion

Similar Posts

Why does ManualResetEventSlim.Set hang when suspending a waiting thread in my C# test?

Why Does ManualResetEvent.Set Deadlock When Suspending a Waiting Thread in C#?

2 Answers

1. Why does the execution stop at suspendEvent.Set()?

2. Why does the initial version work while the refactored one doesn’t?

Summary

Discussion

Similar Posts

Why does ManualResetEventSlim.Set hang when suspending a waiting thread in my C# test?

1. Why does the execution stop at `suspendEvent.Set()`?