4

In a multi-threaded environment, we must consider concurrent access to writable resources. A common approach is to use Monitor or its shorthand form lock.

Task is at a different abstraction level than Thread. A task may run on a thread of its own (and according to the logs, they do so in our application), but that is not guaranteed. See e.g. What is the difference between task and thread?:

If the value you are waiting for comes from the filesystem or a database or the network, then there is no need for a thread to sit around and wait for the data when it can be servicing other requests. Instead, the Task might register a callback to receive the value(s) when they're ready.

That is, that kind of Task somehow shares a Thread with other running code (I must admit that I do not understand how that works in detail, currently it looks to me like a specialization of the "famous" DoEvents).

Consequently, Monitor won't be able to distinguish between them, and - because Monitor can be re-entrant - allow both of them access the resource. That is, Monitor "fails."

Examples with Threads typically use Monitor nonetheless. So I want to ask how I can be sure that Monitor is safe with a Task (or: how can I be sure that a Task is running on a Thread of its own).

Community
  • 1
Bernhard Hiller
  • 1,963

1 Answers1

7

So I want to ask how I can be sure that Monitor is safe with a Task (or: how can I be sure that a Task is running on a Thread of its own).

You don't. You shouldn't be using a Monitor in an asynchronous operation precisely because you can't guarantee this (and wouldn't want to even if you could).

The solution is to use different synchronization mechanisms that are designed to function appropriately in an asynchronous context. They need to not use thread affinity, for example, and you'll also want them to be themselves asynchronous, rather than synchronously waiting for access to the critical section.

The answer is to use SemaphoreSlim, which has a WaitAsync method that you can await. Assuming you have a traditional critical section, you can set the semaphore to only allow 1 concurrent operation. Using this, if a thread gets access to the semaphore, then starts an asynchronous operation and goes off to do something else that also tries to access the semaphore, it won't have access. It also means you won't have any problems releasing the semaphore from a different thread than you acquired it from.

Servy
  • 1,986