Author: natan

• 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

In short: no.

Longer explanation:

• task that want to do I/O write call to driver write
• driver operations are performed asynchronously
• write operations on devices is done without CPU involved
• finish of writing is done via interrupt
• interrupt, schedules Deferred Procedure Call
• DPC schedules Asynchronous Procedure Call
• APC notifies thread that I/O write is done
• task that was doing I/O is scheduled with continuation of its method after I/O is done.
• some threads might need to be borrowed for handling APC and such but no thread is spawn to handle I/O

I recommend reading this post: https://blog.stephencleary.com/2013/11/there-is-no-thread.html. This will explain the topic much better than I can.

Further read:

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model#BKMK_Threads

• avoid doing AsyncOperation.Result
• parent method waits for Result while child method waits for parent thread to take control, after being done with async I/O
• both waits
• deadlock

Further read:

https://medium.com/rubrikkgroup/understanding-async-avoiding-deadlocks-e41f8f2c6f5d

https://stackoverflow.com/questions/15021304/an-async-await-example-that-causes-a-deadlock