C# and .NET have evolved significantly in how they handle threading. The early days of .NET 1.0 gave us System.Threading.Thread, a direct wrapper around OS threads. .NET 2.0 added ThreadPool for efficient thread reuse. Then .NET 4.0 introduced the Task Parallel Library (TPL), which abstracted away much of the manual thread management. And .NET 4.5 brought async/await, making asynchronous code read almost like synchronous code.

Despite all these abstractions, understanding raw threads remains essential. You'll encounter legacy code using them, need them for specific scenarios, and understanding threads helps you reason about what those higher-level abstractions actually do.

This chapter dives deep into C#-specific thread creation. We'll explore the full Thread API, all the ways to create threads, configuration options, lifecycle management, and patterns you'll encounter in production code and interviews.

The Thread Class

At the heart of .NET's threading model is System.Threading.Thread. Every managed thread in a .NET application is represented by an instance of this class.

Thread Constructors

The Thread class provides four public constructors:

The maxStackSize parameter specifies the stack size in bytes. The default on 64-bit systems is 1MB for the main thread and 256KB for threads created via the ThreadPool. You might reduce it when creating many threads to conserve memory, or increase it for deeply recursive algorithms.

Unlike Java, C# doesn't have constructors that accept both a delegate and a thread name. You set the name separately via the Name property.

Key Thread Properties

Every thread exposes several properties that affect its behavior and help with debugging:

Name: A human-readable identifier invaluable for debugging. If not set, Name returns null.

ManagedThreadId: A unique integer identifying the thread within the CLR. Unlike names, IDs are always unique and automatically assigned.

Priority: A ThreadPriority enum value that hints to the scheduler. Higher priority threads may get more CPU time, but this is OS-dependent.

IsBackground: Determines whether the thread prevents application shutdown. Background threads are terminated when all foreground threads complete.

IsAlive: Returns true if the thread has started and hasn't terminated yet.

ThreadState: Returns the current state of the thread as a flags enum (can have multiple values combined).

Thread States

A .NET thread can be in several states, defined by the ThreadState enum. Unlike Java's simple enum, .NET uses flags that can be combined:

You can query a thread's state at any time:

ThreadState is a flags enum, so a background thread that's waiting might have ThreadState.WaitSleepJoin | ThreadState.Background. Use bitwise operations or HasFlag() to check specific states:

Three Ways to Create Threads

C# provides three primary approaches to defining what a thread should execute: using ThreadStart, using ParameterizedThreadStart, and using lambda expressions.

ThreadStart Delegate (No Parameters)

The simplest approach uses a delegate with no parameters and no return value:

This works well when your thread doesn't need any input data. The ThreadStart delegate is defined simply as:

ParameterizedThreadStart Delegate (Object Parameter)

When you need to pass data to a thread, use ParameterizedThreadStart:

The delegate signature is:

The downside here is obvious: the parameter is always object, so you lose compile-time type safety. You must cast inside the method, and mistakes only surface at runtime.

Lambda Expressions (Modern Approach)

The preferred modern approach uses lambda expressions, which provide type safety through closure:

Lambdas are preferred because:

Comparison: ThreadStart vs ParameterizedThreadStart vs Lambda

When to use each:

Thread Configuration

Beyond basic creation, .NET provides several configuration options that affect how threads behave.

Naming Conventions

Good thread names are invaluable when debugging. When analyzing a thread dump from a production server with hundreds of threads, meaningful names make the difference between finding the problem quickly versus spending hours searching.

Common naming patterns:

Important: Thread names can only be set once. Attempting to change an already-named thread throws InvalidOperationException.

Thread Priority

Thread priority hints to the OS scheduler how important a thread is. The mapping between .NET's five priority levels and OS priorities varies by platform:

Important caveats:

Background vs Foreground Threads

This distinction is crucial in .NET. A foreground thread keeps the application alive, while background threads are terminated when all foreground threads complete.

Rules for background threads:

Apartment State (Windows-Specific)

Apartment state is a COM interop concept unique to Windows. It controls how COM objects interact with threads. Most .NET developers never need to worry about it, but it becomes critical when working with certain Windows APIs.

When STA matters:

Thread Lifecycle Management

Understanding how to properly start, wait for, and stop threads is essential for correct concurrent programs.

The Start() Method

Calling Start() tells the CLR to create a new native thread and invoke the thread's delegate on it:

Critical: You can only call Start() once. Calling it again throws ThreadStateException:

If you need to run the same task again, create a new Thread instance.

Join() and Timeouts

The Join() method blocks the calling thread until the target thread terminates:

The overloaded versions:

Thread.Sleep() vs Task.Delay()

Thread.Sleep() pauses the current thread for the specified duration:

In modern async code, prefer Task.Delay() as it doesn't block a thread:

Thread.Sleep(0) yields the current thread's time slice to other threads of equal priority. Thread.Yield() is similar but only yields to threads on the same processor.

Abort() - Deprecated and Removed

In .NET Framework, Thread.Abort() could forcibly terminate a thread by injecting a ThreadAbortException. This was inherently dangerous because:

Important: Thread.Abort() was removed in .NET Core and .NET 5+. Calling it throws PlatformNotSupportedException. Use cooperative cancellation with CancellationToken instead.

Interrupt()

Thread.Interrupt() is less aggressive than Abort(). It causes a ThreadInterruptedException only when the thread is in a waiting state (Sleep, Join, Wait):

Unlike Abort(), the thread must be in a blocked state for the exception to be thrown. If the thread is running CPU-bound code, the interrupt waits until the next blocking call.

The Modern Way: CancellationToken

.NET's recommended approach for stopping threads is cooperative cancellation using CancellationToken. This pattern is used throughout the TPL and async/await.

Basic Pattern

CancellationTokenSource

The CancellationTokenSource (CTS) controls the token:

Timeout Cancellation

CTS can automatically cancel after a timeout:

Linking Tokens

You can create a token that cancels when any of several sources cancel:

Registering Callbacks

You can register callbacks that run when cancellation is requested:

Returning Results from Threads

Getting results back from threads is a common requirement. C# provides several approaches.

Shared Variables with Lock

The traditional approach uses shared variables with proper synchronization:

This works but requires careful synchronization and is error-prone.

Thread-Local Storage (ThreadLocal<T>)

When each thread needs its own copy of a value:

TaskCompletionSource Pattern

When you need to return results from thread-based code to Task-based callers:

Why Task<T> is Preferred

For most scenarios, you should skip raw threads entirely and use Task<T>:

ThreadPool Basics

Creating a new thread is expensive: it involves OS calls, memory allocation for the stack, and scheduling overhead. The ThreadPool maintains a pool of worker threads that can be reused for multiple tasks.

Using the ThreadPool

ThreadPool Properties

ThreadPool vs Raw Threads

When to use raw threads:

When to use ThreadPool:

In practice, use Task.Run() which uses the ThreadPool internally but provides a richer API.

Common Patterns

Fire-and-Forget Pattern

For tasks where you don't need the result:

Caveat: Fire-and-forget with background threads means the work might not complete if the app exits. For important work, use foreground threads or proper async patterns with graceful shutdown.

Worker Thread with Loop Pattern

A long-lived thread that processes items:

Background Cleanup Daemon Pattern

A background thread for periodic maintenance:

Producer-Consumer Setup Pattern

Multiple producers and consumers sharing a queue: