In a multi-threaded environment, we must consider concurrent access to writable resources. A common approach is to use
Monitor or its shorthand form
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"
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,
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).