Manual Threads vs. Task.Factory: Optimizing Long-Running Workers In .NET development

Godwin Oluowho — Mon, 30 Mar 2026 13:52:35 +0000

choosing between a Manual Thread and Task.Factory.StartNew for long-running background workers has direct implications for system stability and resource efficiency. While both move work to a background execution context, they handle blocking, resource allocation, and errors differently.

Thread Pool Health and Resource Usage A manual thread (new Thread()) creates a dedicated OS resource. If your worker uses GetResult() to wait on asynchronous operations, that thread remains "pinned" and idle during I/O, consuming memory and stack space without performing work.

Task.Factory.StartNew with TaskCreationOptions.LongRunning acts as a hint to the Task Scheduler. It typically creates a dedicated thread to avoid Thread Pool Starvation, ensuring that your long-running workers do not block the pool of threads needed for short, bursty tasks like HTTP requests.

To make the comparison concrete, here is how the two approaches look when implemented inside a Custom WorkerManager for Processing .

Manual Thread Implementation (Legacy Pattern)

In this version, we are forced to block the OS thread to keep the worker alive, and error handling is disconnected from the main application lifecycle.

public class WorkerManager
{
    private readonly List<Thread> _workers = new();

    public void StartWorkers(int count)
    {
        for (int i = 0; i < count; i++)
        {
            var worker = new Worker(i);

            // This allocates a dedicated OS thread (approx. 1MB stack)
            var thread = new Thread(() => 
            {
                // DANGER: .GetResult() blocks the thread during I/O.
                // If an exception occurs here, the process may crash.
                worker.Run().GetAwaiter().GetResult();
            })
            {
                IsBackground = true
            };

            _workers.Add(thread);
            thread.Start();
        }
    }
}

Task.Factory Implementation (Modern Pattern)

This approach uses the Task Parallel Library (TPL) to manage the execution. It allows for non-blocking I/O and captures exceptions within the Task object itself.

public class WorkerManager
{
    private readonly List<Task> _workers = new();
    private readonly CancellationTokenSource _shutdownCts = new();

    public void StartWorkers(int count, IServiceScopeFactory scopeFactory)
    {
        for (int i = 0; i < count; i++)
        {
            var workerId = i;
            var worker = new Worker(workerId, scopeFactory, _shutdownCts.Token);

            // Task.Factory.StartNew returns a Task<Task> because of the async lambda.
            // .Unwrap() flattens it so we can track the actual internal 'Run' logic.
            var taskResult = Task.Factory.StartNew(
                async (object? _) =>
                {
                    Thread.CurrentThread.Name = $"Worker-Thread-{workerId}"; 
                    // Non-blocking: The thread can be released during 'await'.
                    await worker.Run();
                },
                state: null,
                cancellationToken: _shutdownCts.Token,
                creationOptions: TaskCreationOptions.LongRunning, // Bypass ThreadPool
                scheduler: TaskScheduler.Default
            ).Unwrap(); 

            _workers.Add(taskResult);
        }
    }
}

Understanding Expression Trees in C# Through a Practical Example

Godwin Oluowho — Tue, 03 Mar 2026 17:44:39 +0000

Expression trees in C# allow you to represent code as data. Instead of executing a method directly, you can inspect its structure at runtime. This is widely used in LINQ providers, ORMs, and background job systems.

This article explains expression trees using a practical method pattern commonly seen in background processing systems.

Assume we want to schedule a method call for later execution. Instead of calling the method directly, we pass it as an Expression<Action>:

public class FireAndForgetJobs
{
    private Expression<Action> _expression;

    public FireAndForgetJobs(Expression<Action> expression)
    {
        _expression = expression; 
    }

    public async Task ExecuteAsync(CancellationToken token)
    {    
        MethodCallExpression? methodCall =
            (MethodCallExpression)_expression.Body;

        string functionName = methodCall.Method.Name;
        Type typeName = methodCall.Method.DeclaringType;

        // Logic here to invoke method dynamically
    }
}

Now let's break down what is happening.

What Is an Expression Tree?

An expression tree is an object representation of code.

Normally, when you write:

DoSomething();

The method executes immediately.

But when you write:

Expression<Action> expr = () => DoSomething();

You are not executing the method.
You are creating a tree structure that represents:

The method being called
The declaring type
The arguments (if any)

The compiler builds a data structure instead of compiled instructions.

This structure lives in:

System.Linq.Expressions

Why Use Expression Trees?

Expression trees allow you to:

Inspect the method name
Extract parameter values
Identify the declaring type
Serialize invocation metadata
Reconstruct and execute the call later

This is how libraries like Hangfire capture background job definitions.

Understanding the Code Step-by-Step

1. Capturing the Expression

Expression<Action> expression

This means:

No return value
Represents a method call
Stored as a tree

If someone passes:

new FireAndForgetJobs(() => SendEmail("admin@test.com"));

Nothing executes yet.

2. Accessing the Body

_expression.Body

The body of this lambda is a MethodCallExpression.

So we cast:

(MethodCallExpression)_expression.Body

Now we can access:

methodCall.Method.Name
methodCall.Method.DeclaringType
methodCall.Arguments

3. Extracting Metadata

string functionName = methodCall.Method.Name;
Type typeName = methodCall.Method.DeclaringType;

This gives:

The exact method name
The class it belongs to

You now have enough information to:

Store this in a database
Serialize it
Invoke it using reflection

What the Expression Tree Actually Contains

For this lambda:

() => SendEmail("admin@test.com")

The tree roughly looks like:

LambdaExpression
 └── MethodCallExpression
      ├── MethodInfo
      └── Arguments
           └── ConstantExpression ("admin@test.com")

It is a structured object graph.

Why Not Use Delegates?

A delegate (Action) executes directly.
You cannot inspect:

Method name
Parameters
Target type

With Expression<Action>, you can inspect everything before execution.

This makes it ideal for:

ORMs (e.g., translating LINQ to SQL)
Job schedulers
Rule engines
Dynamic query builders

Limitations

Expression trees:

Cannot represent all C# syntax
Have performance overhead during inspection
Require careful casting (incorrect casts cause runtime errors)

They are powerful but should be used intentionally.

When to Use Expression Trees

Use them when you need:

Code analysis at runtime
Metadata extraction
Dynamic query translation
Delayed execution with introspection

Do not use them for simple method invocation.

Conclusion

Expression trees convert executable code into a structured data model. In the example shown:

The method call is captured.
Its metadata is extracted.
It can be stored and executed later.

This pattern underpins many advanced .NET systems and enables flexible runtime behavior without hardcoding execution paths.

If you are building background processing, dynamic execution engines, or LINQ providers, expression trees are a fundamental tool.

DEV Community: Godwin Oluowho