The full source code for the Concurrent Processing Demo is available on GitHub

Concurrent Processing

Learning Concurrent Processing Through Code

As a developer, one of the most exciting aspects of programming is the opportunity to learn new concepts and techniques. Recently, I embarked on a journey to understand concurrent processing better, and I'm excited to share my experience with you.

The idea of managing multiple tasks simultaneously has always fascinated me. However, it can be a complex challenge, requiring synchronization and careful management to avoid issues like race conditions and deadlocks. To dive into this topic, I decided to develop a C# console application that would allow me to experiment and learn practically.

Considerations for Concurrent Processing

Task Autonomy and Independence
For multiple tasks to effectively run concurrently, each task must encapsulate an autonomous and self-contained unit of functionality. Autonomy ensures that a task operates independently, free from unnecessary dependencies on other tasks or shared resources. By embodying its inputs, logic, and outputs, an autonomous task can be executed without hindrance, allowing it to be scheduled and managed alongside other tasks concurrently. This approach not only enhances the efficiency and responsiveness of the overall system but also minimizes the potential for contention and synchronization issues.
Ensuring proper synchronization is crucial to prevent race conditions and ensure data consistency among multiple threads or tasks. Techniques like locks, semaphores, and monitors can be used to control access to shared resources.
Consider the scalability of your concurrent processing solution. Will it perform well as the number of concurrent tasks or threads increases? Design your system to handle increased load without degrading performance.
Deadlocks and Livelocks
Be aware of potential deadlocks and livelocks that can occur when multiple threads are waiting for resources that are held by other threads. Avoid circular dependencies and ensure proper resource allocation/release to prevent these issues.
Resource Management
Properly manage resources such as memory, file handles, and network connections. Failing to release resources can lead to resource exhaustion and degrade system performance.
Thread Safety
Ensure that your code is thread-safe. Thread safety means that the behavior of a program remains consistent when multiple threads are executing simultaneously. Use techniques like immutable data, synchronization, and thread-local storage.
Load Balancing
Distribute tasks evenly among threads or processing units to ensure efficient utilization of resources. Load balancing helps prevent scenarios where some threads are idle while others are overloaded.
Task Granularity
Determine the appropriate level of task granularity. Too fine-grained tasks can lead to overhead due to thread management, while too coarse-grained tasks might not fully utilize available resources.
Error Handling
Implement robust error-handling mechanisms for concurrent tasks. Unhandled exceptions in one task should not crash the entire application.
Testing and Debugging
Testing concurrent code is challenging. Consider using techniques like stress testing and race condition detection tools to identify issues. Debugging concurrent issues can be complex, so use tools and techniques that help diagnose problems.
Communication and Coordination
Threads or tasks might need to communicate and coordinate with each other. Consider using mechanisms like message queues, shared memory, and events to facilitate inter-thread communication.

Potential Drawbacks in Concurrent Programming

While concurrent programming boosts performance and resource utilization, it comes with challenges:

  • Risk of Deadlocks and Livelocks.
  • Difficulty in Debugging and Testing.
  • Potential for Race Conditions.
  • Increased Memory Consumption.
  • Complexity in Code Management and Maintenance.

By understanding these challenges, developers can employ strategies to mitigate risks and harness the benefits of concurrency in their projects.

Since this was a one-off project, I didn't want to spend too much time on the user interface. I created a repository to create a simple console application that would allow me to focus on the core functionality. View the Concurrent Processing C# Project on GitHub

I started with a ChatGPT prompt that introduced me to the basics of concurrent processing. Armed with this initial guidance, I started writing the code. Before long I had the basic scaffolding in place, and I was ready to start iterating and learning.

More on the SemaphoreSlim Class
const int maxConcurrency = 100; // Maximum concurrent tasks allowed
SemaphoreSlim semaphore = new(maxConcurrency);
List<Task> tasks = new();
int? taskId = 0;
while (taskId is not null)
  Task task = ProcessAsync(taskId.Value, tasks.Count, await AwaitSemaphoreAsync(semaphore), semaphore);
  taskId = GetNextTaskId(taskId);

  if (tasks.Count >= maxConcurrency)
    Task finishedTask = await Task.WhenAny(tasks);
await Task.WhenAll(tasks);

I created a function to wait for a semaphore to be released and added some telemetry to track the time spent waiting.

//  Wait for semaphore to be released so that next task can start
static async Task<long> AwaitSemaphoreAsync(SemaphoreSlim semaphore)
  Stopwatch stopwatch = Stopwatch.StartNew();
  await semaphore.WaitAsync();
  return stopwatch.ElapsedTicks;

I created a mock async processing method that simulates work by delaying for a random amount of time. I also added telemetry data so that I could track the task ID, task count, semaphore count, and wait time. I used the `Task.Delay` method to simulate work, but in a real-world application, this would be replaced with actual work. The random delay was added to simulate the dynamic nature of concurrent processing.

// Mock Async Task to simulate work
static async Task ProcessAsync(int taskId, int taskCount, long waitTicks, SemaphoreSlim semaphore)
    await Task.Delay(TimeSpan.FromMilliseconds(new Random().Next(1, 500)));
    Console.WriteLine($"Task:{taskId:D3} T:{taskCount} S:{semaphore.CurrentCount} W:{waitTicks}");

Finally, I created a function to generate the next task ID. This is how I controlled the number of tasks that were created.

// Get Next Task ID
static int? GetNextTaskId(int? taskId)
  if (taskId &lt; 1000) return taskId + 1;
  else return null;

Iterating and Learning

As I dove into the code, I realized that understanding concurrent processing goes beyond just knowing how to create threads or tasks. I needed to comprehend the concept of synchronization and how to manage the number of concurrently executing tasks. The code I had started with was a great foundation, but it required iteration and refinement to achieve my goals.

The heart of the application was the use of the `SemaphoreSlim` class, which acted as a gatekeeper to control the number of tasks running concurrently. This was a crucial lesson in managing shared resources and preventing resource exhaustion.

Experimenting and Observing

With each iteration of the code, I ran the application and observed its behavior. The output of the program provided valuable insights into how tasks were being managed, the time each task spent waiting for a semaphore, and the overall concurrency control.

Task:061 T:61 S:2 W:2
Task:070 T:70 S:0 W:4
Task:037 T:37 S:0 W:2
Task:018 T:18 S:3 W:2
Task:023 T:23 S:1 W:2
Task:026 T:26 S:2 W:3

The output highlighted the dynamic nature of concurrent processing, where tasks were processed and released in a controlled manner, ensuring that the maximum concurrency was maintained while avoiding resource contention.

Celebrating Success

After several iterations, moments of frustration, and numerous debug sessions, I finally achieved my desired result. The application was now a well-functioning demonstration of concurrent processing, showcasing my newfound understanding of synchronization and resource management.

The journey was not just about the code; it was about the learning process itself. Developing this console application was a great learning tool that allowed me to grasp the intricacies of concurrent processing hands-on. It transformed abstract concepts into tangible knowledge.


The world of concurrent processing is complex and fascinating. Through the development of this C# console application, I gained valuable insights into managing multiple tasks simultaneously while avoiding common pitfalls. The iterative process of refining the code helped me internalize the concepts and apply them effectively.

I encourage fellow developers to try learning through practical coding. It's one thing to read about a topic, but a whole different experience to see it in action and work through challenges firsthand. With the right resources, curiosity, and determination, you can turn any coding endeavor into a powerful learning tool.

Happy coding and exploring the world of concurrency!

The SemaphoreSlim Class

Back to Top

The SemaphoreSlim class in .NET presents a robust solution for fine-tuning resource utilization. This lightweight semaphore is designed for scenarios where wait times are expected to be short, making it ideal for controlling the number of tasks executing in parallel within a single process.

The SemaphoreSlim class offers a simple, yet effective way to limit the number of threads that can access a specific resource or a pool of resources concurrently. This is particularly useful in scenarios where you need to throttle the usage of resources like network bandwidth or CPU time, preventing the system from being overwhelmed.

When integrating SemaphoreSlim into the Task List Processor, it allows precise control over the number of tasks running simultaneously. By setting the maximum concurrent tasks, we ensure efficient execution without overloading the system, especially crucial in high-load situations.

For more detailed information on SemaphoreSlim , its usage, and examples, visit the Microsoft Documentation on SemaphoreSlim .

Semaphore vs SemaphoreSlim in .NET

Choose Semaphore when you need inter-process synchronization or when dealing with named semaphores for system-wide visibility. Opt for SemaphoreSlim for more lightweight, intra-process synchronization where performance and efficiency are key considerations


A wrapper around the Win32 semaphore object, suitable for local or system-wide named semaphores.
Ideal for thread synchronization across multiple processes or for inter-process communication.
Slower and more resource-intensive, relying on the system's kernel mode.
Supports system-wide visibility and waiting on multiple semaphores.
Synchronizing resource access across different applications on the same system.
Visibility across processes, suitable for complex synchronization.
Heavier, slower, and suitable for long wait times. Involves kernel transitions.


Lightweight and fast, designed for use within a single process.
Best for short wait times and scenarios confined to a single process.
More efficient in memory and speed, using CLR synchronization primitives.
Does not support named semaphores or system-wide visibility.
Limiting concurrent calls to an external service in a web server application.
Faster, more memory-efficient, suited for fine-grained control within an app.
Not suitable for inter-process communication, lacks system-wide visibility.