Author: natan

• simplify process of adding parallelism and concurrency to application
• scales concurrency automatically
• data parallelism
• task based async programming
• data flow

Further read:

https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/task-parallel-library-tpl

In short:

it will not work because it requires boxing and boxing will create new object for reference in lock every time code is executed so lock statement will not prevent anything.

Further read:

https://intellitect.com/blog/locking-a-block-of-code-with-an-integer/

• lock statement blocks execution of a code block for single thread that hold lock
• the same thread can acquire and release lock again
• any other thread is blocked from the statement
• lock on dedicated instance only
• using the same instance on multiple lock statements may lead to deadlock
• avoid using as lock
  • this, as it might be used by the callers as a lock
  • Type instances, as those might be obtained by the typeof operator or reflection
  • string instances, including string literals, as those might be interned
• Hold a lock for as short time as possible to reduce lock contention.

Below code block is translated by compiler

lock (x)
{
    // Your code...
}

to:

object __lockObj = x;
bool __lockWasTaken = false;
try
{
    System.Threading.Monitor.Enter(__lockObj, ref __lockWasTaken);
    // Your code...
}
finally
{
    if (__lockWasTaken) System.Threading.Monitor.Exit(__lockObj);
}

Further read:

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/lock

• task is asynchronous operation
• thread is abstraction on OS thread

Further read:

https://www.c-sharpcorner.com/article/task-and-thread-in-c-sharp/

• multi threaded programs usually uses one of the threads as means of synchronization
• there are message loops to pass unit of works (like Windows message queue)
• message queues require messages formats and convention for handling it
• single thread to handle ASP.NET request is waste of the resources (before .NET 2)
• thread pool was better but inconvenient to work with
• instead SynchronizationContext queues work for given context not thread
• thread have current context
• context does not have to be unique but can be shared between multiple threads
• thread can change context but this is rare
• SynchronizationContext keeps count of all asynchronous operations
• Windows Forms uses WindowsFormsSynchronizationContext
• WPF and Silverlight uses DispatcherSynchronizationContext
• Console app and WindowsServices and ThreadPool threads uses default SynchronizationContext
• ASP.NET uses AspNetSynchronizationContext

Further read:

https://learn.microsoft.com/pl-pl/archive/msdn-magazine/2011/february/msdn-magazine-parallel-computing-it-s-all-about-the-synchronizationcontext