-1

I like threads, but I can't find any information on the Internet (maybe I just don't Know how to search for that properly) regarding what happen in the background when for example thread starvation is on the stage. How does OS handles it? Do my thread waits in the line to get it's chance to be created in the thread pool or is it killed after xy time when it can't be created? Or is it something totally else?

Another question is why should I care about thread context? By calling ConfigureAwait(false) from what I know I am not waiting for that thread context which can be translated as "I don't care about that context". From what I know by calling ConfigureAwait(false) I am taking care of deadlocks.

The last question is, when a deadlock happen, what is going on in the background? Do main thread tries to catch that context or something else?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Ryukote
  • 767
  • 1
  • 10
  • 26
  • "why should I care about thread context?" - Because sometimes it _is_ important to continue on the same thread. Think : UI Thread. – Fildor Mar 29 '18 at 07:40
  • But as I understand (which might be wrong), ConfigureAwait is by default true, which means I can get deadlocks which is not what anyone wants. But if I set it to false, I am taking care of deadlocks, which means I will not wait for context of newly created thread. – Ryukote Mar 29 '18 at 07:42
  • Yes, so? All I am saying is there are situations where context _is_ important and thus you _should_ care. – Fildor Mar 29 '18 at 07:45
  • Can you explain situations where I should care about context and where I shouldn't? If I understand you correctly, I should care about a context when I am returning some Task to the main (UI) thread, and I should not care when I am doing something that should not be returned on the main (UI) thread? And how do you avoid deadlocks on the main thread if you set false to ConfigureAwait if you want to care about a context? – Ryukote Mar 29 '18 at 07:48
  • Maybe google [Stephen C's blog](https://blog.stephencleary.com/) and what he has to say about these topics. – Fildor Mar 29 '18 at 07:51
  • Ok I got most of it. But question about thread pool still remains. – Ryukote Mar 29 '18 at 08:03

1 Answers1

0

I think deadlock is used in the wrong context here. Deadlock describes a situation where two or more threads are blocked forever, waiting for each other (e.g. by lock statement).

Thread starvation: Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress.

Do my thread waits in the line to get it's chance to be created in the thread pool or is it killed after xy time when it can't be created?

I don't really understand this question. Your thread doesn't wait to be created. Your function creates the thread.

Another question is why should I care about thread context?

From MSDN: "A context is an ordered sequence of properties that define an environment for the objects resident inside it. Contexts get created during the activation process for objects that are configured to require certain automatic services, such as synchronization, transactions, just-in-time activation, security, and so on. Multiple objects can live inside a context."

Here a similar question :Why would I bother to use Task.ConfigureAwait(continueOnCapturedContext: false);

The last question is, when a deadlock happen, what is going on in the background?

The two threads keep running (waiting for each other) until you close the application.

Mardukar
  • 415
  • 2
  • 11
  • To the part you didn't understand. I will try to reconstruct my question. If thread pool is full and there can't be any more threads in the pool. What will happen with a thread I want to create? – Ryukote Mar 29 '18 at 10:31
  • 1
    all explained here: https://msdn.microsoft.com/de-de/library/system.threading.threadpool(v=vs.110).aspx – Mardukar Mar 29 '18 at 10:52
  • This one is nice. With all those replies, I got all the answers I wanted. Thanks. – Ryukote Mar 29 '18 at 11:23