Introduction

ManualResetEvent belongs to the older blocking side of .NET concurrency, while await belongs to the task-based asynchronous model. If a legacy API exposes a ManualResetEvent, you often need a bridge that lets async code wait for it without parking a thread the whole time.

The important point is that "awaitable" does not mean "run WaitOne() inside Task.Run." That works, but it defeats much of the reason to use async code in the first place.

Why Task.Run(() => WaitOne()) Is A Weak Bridge

A first attempt often looks like this:

await Task.Run(() => manualResetEvent.WaitOne());

Functionally, that completes when the event is signaled. Operationally, it burns a thread-pool thread for the entire wait. If the event is signaled quickly, the waste is small. If it stays unsignaled for seconds or minutes, or if many waits exist at once, the thread-pool cost becomes real.

That is why a registration-based bridge is better. You want the runtime to observe the wait handle and complete a Task when the signal arrives, not dedicate a worker thread to sleep inside WaitOne().

Use ThreadPool.RegisterWaitForSingleObject

The standard pattern is ThreadPool.RegisterWaitForSingleObject plus TaskCompletionSource. The registration asks the runtime to invoke a callback when the wait handle is signaled.

1using System;
2using System.Threading;
3using System.Threading.Tasks;
4
5public static class WaitHandleExtensions
6{
7    public static Task WaitAsync(
8        this WaitHandle handle,
9        CancellationToken cancellationToken = default)
10    {
11        var tcs = new TaskCompletionSource<object?>(
12            TaskCreationOptions.RunContinuationsAsynchronously);
13
14        RegisteredWaitHandle? registration = null;
15        CancellationTokenRegistration ctr = default;
16
17        registration = ThreadPool.RegisterWaitForSingleObject(
18            handle,
19            static (state, _) =>
20            {
21                var tuple = ((TaskCompletionSource<object?>, RegisteredWaitHandle?, CancellationTokenRegistration))state!;
22                tuple.Item1.TrySetResult(null);
23                tuple.Item2?.Unregister(null);
24                tuple.Item3.Dispose();
25            },
26            null,
27            Timeout.Infinite,
28            true);
29
30        if (cancellationToken.CanBeCanceled)
31        {
32            ctr = cancellationToken.Register(() =>
33            {
34                tcs.TrySetCanceled(cancellationToken);
35                registration?.Unregister(null);
36            });
37        }
38
39        registration?.Unregister(null);
40        registration = ThreadPool.RegisterWaitForSingleObject(
41            handle,
42            (state, _) =>
43            {
44                var data = ((TaskCompletionSource<object?>, RegisteredWaitHandle?, CancellationTokenRegistration))state!;
45                data.Item1.TrySetResult(null);
46                data.Item2?.Unregister(null);
47                data.Item3.Dispose();
48            },
49            (tcs, registration, ctr),
50            Timeout.Infinite,
51            true);
52
53        return tcs.Task;
54    }
55}

That code gives the caller a proper Task to await and avoids blocking a thread for the whole wait duration.

Use The Wrapper From Async Code

Once the extension exists, using it looks natural:

1using System;
2using System.Threading;
3using System.Threading.Tasks;
4
5var mre = new ManualResetEvent(false);
6
7_ = Task.Run(async () =>
8{
9    await Task.Delay(500);
10    mre.Set();
11});
12
13await mre.WaitAsync();
14Console.WriteLine("Signal received");

Because ManualResetEvent stays signaled until someone calls Reset(), multiple awaiters can pass after Set() if you use it that way. That is different from AutoResetEvent, where one signal normally releases one waiter.

Add Cancellation And Lifetime Rules

If the signal might never arrive, cancellation is essential. Otherwise the awaited task can remain incomplete forever.

1using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(2));
2
3try
4{
5    await mre.WaitAsync(cts.Token);
6}
7catch (TaskCanceledException)
8{
9    Console.WriteLine("Canceled while waiting");
10}

You also need a clear lifetime rule for the underlying wait handle. If some other code disposes the ManualResetEvent while the async wait is still active, the behavior becomes hard to reason about. In practice, the owner of the event should ensure the handle outlives all pending waits or that pending waits are canceled before disposal.

Consider An Async-Native Alternative

If you control the design, it is often better to stop exposing ManualResetEvent at all. An async-native primitive such as an AsyncManualResetEvent built on TaskCompletionSource is usually easier to compose in modern code.

1using System.Threading.Tasks;
2
3public sealed class AsyncManualResetEvent
4{
5    private TaskCompletionSource<bool> tcs =
6        new(TaskCreationOptions.RunContinuationsAsynchronously);
7
8    public Task WaitAsync() => tcs.Task;
9    public void Set() => tcs.TrySetResult(true);
10
11    public void Reset()
12    {
13        if (tcs.Task.IsCompleted)
14        {
15            tcs = new TaskCompletionSource<bool>(
16                TaskCreationOptions.RunContinuationsAsynchronously);
17        }
18    }
19}

This avoids bridging two concurrency models and usually produces cleaner application code.

Common Pitfalls

One common mistake is assuming Task.Run makes a blocking wait "async enough." It does not. Another is forgetting to unregister the wait callback after completion or cancellation, which can leave registrations hanging around longer than intended. Developers also sometimes treat ManualResetEvent like AutoResetEvent and get surprising behavior when many awaiters all pass after one signal. Finally, if you truly own the API, exposing a blocking primitive to async callers is often the design smell that should be fixed instead of wrapped.

Summary

• 'ManualResetEvent is blocking, so a good async wrapper should avoid a dedicated blocked thread.'
• 'ThreadPool.RegisterWaitForSingleObject plus TaskCompletionSource is the usual bridge.'
• Add cancellation so async callers can stop waiting predictably.
• Be explicit about lifetime and disposal of the underlying wait handle.
• If you control the design, prefer an async-native reset event instead of wrapping a legacy primitive.