Author: natan

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

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