Hello everyone! For many years, I have been developing equipment control software and long-term support products using .NET/C#. Based on the experiences gained through working with various development teams, I would like to talk about why I created CALM (Cooperative Async Lock-free Messaging), an open-source library for .NET.

The Magic of UI Thread + Event-Driven + async/await

My journey with .NET/C# began around the days of .NET Framework 4.0. At the time, code-behind in Windows Forms was incredibly intuitive. It allowed me to join the development team and become productive in a very short period.

Back then, executing time-consuming operations on a separate thread and returning the results to the UI thread via callbacks was painful and error-prone. However, the introduction of async/await in .NET Framework 4.5 completely shifted the paradigm. The SynchronizationContext magically handled thread marshaling behind the scenes, and our code became amazingly simple.

"Running asynchronous operations safely on a single thread (the UI thread) via an event-driven approach" — this seamless developer experience was my starting point.

Divide and Conquer, Dependency Management, and CQS

As our product evolved, the codebase grew, and the development team expanded beyond a certain size. Suddenly, the software became exponentially complex. Following industry best practices, we introduced MVP and MVVM patterns to separate the UI from the business logic. We also refactored our domain models based on Domain-Driven Design (DDD) and Clean Architecture principles, alignment with the team's domain knowledge.

While this helped organize the logic within individual models, it introduced a new nightmare: complex dependencies between models. We struggled heavily with initialization, especially with models that had circular or mutual dependencies.

To break this web of tight coupling, we introduced a mechanism that combined the Observer pattern (inspired by Android's EventBus) with the philosophy of CQS (Command Query Separation). By leveraging message-based, loosely coupled communication, we successfully eliminated direct dependencies.

The Trap of Multi-Threading and Race Conditions

However, as the system evolved, the backend model layer—now completely detached from the UI thread—transformed into a concurrent wild-west where numerous background threads crossed paths.

Writing concurrent code while keeping multi-threading issues in mind is incredibly delicate; even senior engineers frequently get flagged by static analysis tools. For junior engineers, it is an uphill battle to fully understand atomic operations or context switching, and constantly choose the right tool from the concurrency toolbox:

• Heavy-handed synchronization via lock or SemaphoreSlim
• Thread-safe collections like ConcurrentDictionary
• Low-level optimizations with Interlocked or Volatile

"What we really need to focus on is not low-level concurrency control. It should be pure business logic."

Faced with this dilemma, the team made a radical decision: "Let's run the backend model layer on a dedicated, single-threaded event loop, just like the UI thread."

At the time, we drew inspiration from Unity's Coroutines. As long as developers understood the simple rule of using yield return instead of Thread.Sleep or Task.Delay, anyone could easily write safe logic without worrying about race conditions. Although there were limitations—such as not being able to use yield inside try/catch blocks or blocking other operations during heavy I/O—we could easily work around them, making it a perfectly acceptable trade-off.

8 Years Later: The Birth of CALM

Today, I work as a freelancer. Over the years, I found that the "single-threaded execution engine + CQS messaging" approach I built in the past was still highly effective for solving complexity in modern applications.

This realized potential led me to redesign the entire concept from scratch for modern .NET and release it as an open-source library called CALM.

https://github.com/nullmake/calm-dotnet

The core mission of CALM is to bring that nostalgic simplicity of "UI Thread + Event-Driven + async/await" directly into backend and equipment-control logic layers.

1. Unleashing Power with Native Tasks (async/await)

The biggest drawbacks of the old coroutine era—such as try/catch constraints and I/O blocking—have been completely solved by building the execution engine natively on top of C# Task (async/await).

2. Consistency via Outbox / Unit of Work

To make the CQS pattern more robust, CALM natively integrates the Unit of Work and Outbox patterns. Internal events published during a command handler's execution are deferred; they are only dispatched to the message queue once the command (the async method) completes successfully. This prevents state inconsistencies when unexpected errors occur halfway through an operation.

3. Guardrails via a Powerful Roslyn Analyzer (Boosting DX)

To get the most out of a single-threaded messaging loop, there is one absolute rule: Never unintentionally escape the engine thread. To save developers from the mental burden of tracking this, CALM comes bundled with a dedicated Roslyn Analyzer.

It instantly detects invalid handler signatures and warns you about accidental thread escapes caused by ConfigureAwait(false) right in your IDE or during build time.

4. Intentional Multi-Threading Offloading

You might wonder: "If everything runs on a single thread, won't heavy CPU-bound tasks block the entire system?" CALM solves this elegantly. For heavy operations that do not suffer from race conditions—such as re-archiving a ZIP file to reduce its size—CALM explicitly allows you to use .ConfigureAwait(false) to offload the work to the ThreadPool. This gives developers the flexibility to explicitly control concurrency while staying safely within the guardrails.

---

Conclusion

When creating this library, the hardest part was choosing the right name and description. Technically speaking, its role is:

CALM (Cooperative Async Lock-free Messaging)
A lock-free, single-thread messaging library for .NET.

However, what I truly wanted to solve with this library is a fundamental developer question: "How can we free ourselves from the fear of multi-threading and keep our code elegantly simple?"

It is not as generic as MediatR, nor as heavyweight as Akka.NET. It brings back that exact sense of security and ease we felt when writing events on the UI thread, applying it directly to complex backend state management.

I hope this story gives you some inspiration for your battle against software complexity. If you find the project interesting, please consider dropping a star or sharing your feedback!

• GitHub: nullmake/calm-dotnet
• Document: CALM Documentation
• NuGet: Calm.Core

Thank you for reading until the end!