How To Achieve Synchronization In C# While Doing Async Await Multithreaded Programming - .NET Core

Показать описание

0:00 Introduction to How To Achieve Synchronization In C# While Doing Async Await Multithreaded Programming
0:32 The objects we are going to use
2:00 How we gonna test and compare Mutex, SemaphoreSlim and ReaderWriterLockSlim
2:47 Why use local variable to prevent data race
4:44 Sub method that will call writing method with await keyword
5:24 Why define long variables to debug application with Interlocked.Increment
5:42 Write to file method where we are doing locking and synchnorşization
6:06 Method call vs when lock is obtained
7:19 Why we need to use Interlocked
9:21 Why we are using finally method when working different locking mechanisms
10:54 How to test how actually each synchronization method (Mutex, SemaphoreSlim, ReaderWriterLockSlim) works
12:30 What happened in the lock acquiring part of the method call
14:00 Testing not properly working synchronization method ReaderWriterLockSlim
15:22 Testing not properly working synchronization method Mutex
17:25 Why Mutex is not the correct choice for synchronization of async await using multi-threaded programming

Mutex, SemaphoreSlim, and ReaderWriterLockSlim are all synchronization primitives that can be used in .NET Core to control access to shared resources.

A Mutex (short for "mutual exclusion") is a synchronization object that allows only one thread to enter a critical section at a time. It is used to protect shared resources from concurrent access, which can cause race conditions and other types of errors. A Mutex can be owned by a single thread, and other threads that attempt to acquire the Mutex will be blocked until the owning thread releases it.

SemaphoreSlim is similar to a Mutex in that it controls access to a shared resource, but it allows multiple threads to enter the critical section simultaneously. A SemaphoreSlim has a count that represents the number of threads that can enter the critical section simultaneously. When a thread tries to enter the critical section, the count is decremented. If the count is zero, the thread is blocked until the count is increased by another thread exiting the critical section.

ReaderWriterLockSlim is a synchronization primitive that is designed to optimize access to shared resources that are read frequently and written infrequently. It allows multiple threads to read the shared resource simultaneously, but only one thread can write to it at a time. This can greatly improve performance in scenarios where many threads are reading the shared resource but only a few are writing to it.

All three synchronization primitives are useful in different scenarios and have their own advantages and disadvantages.

Mutex is a powerful synchronization primitive that can be used to protect shared resources from concurrent access. It is easy to use and understand, and it can be used to synchronize access to shared resources across multiple processes. However, it can be slow and can cause contention if used excessively.

SemaphoreSlim is a good choice when you need to synchronize access to a shared resource that can be used by multiple threads simultaneously. It allows multiple threads to enter the critical section at the same time, which can improve performance in some scenarios. However, it can also cause contention if used excessively.

ReaderWriterLockSlim is a good choice when you need to optimize access to shared resources that are read frequently and written infrequently. It allows multiple threads to read the shared resource simultaneously, which can greatly improve performance in scenarios where many threads are reading the shared resource but only a few are writing to it. However, it can be more complex to use and understand than Mutex or SemaphoreSlim.

In summary, Mutex, SemaphoreSlim and ReaderWriterLockSlim are all useful synchronization primitives in different scenarios. They all can be used to control access to shared resources in multi-threaded environment and can help prevent race conditions and other types of errors. The choice of which one to use will depend on the specific requirements of your application.