Thread lifecycle in .NET framework

Question

The state of a thread in .NET framework is explained in this link.

I recently saw this picture in a web-site and a couple of questions came to my mind:

1. The thread lifecycle in the OS is not completely aligned with thread lifecycle in .NET framework. Can someone provide a resource that matches the states in OS with .NET framework?

2. We don't have a state called Blocked in .NET framework. What will be the state of a thread if it issues an I/O request?

3. What is the purpose of the Aborted state? When a thread calls the Abort() method, it will go to the AbortRequested state and after the thread responds to abort request, it will go to Stopped state. So what is the function of Aborted state?

Aglimmer

Answer 1

A thread is blocked if its execution has been suspended by one of the synchronization primitives, such as a lock or a mutex. Any thread that is performing useful work at a given moment is, by definition, not blocked at that moment.

The AbortRequested/Stopped cycle gives the thread an opportunity to perform an orderly shutdown, releasing acquired resources and performing other cleanup tasks.

http://www.albahari.com/threading/

Blasted

1. but .net framework does not have any state called Blocked. If a thread is blocked by the OS (I/O request or as u mentioned by lock or mutex), what will be the state of it ? 2. yes you are right, but each OS has a predefined thread life cycle. Linux has one, Windows also has one. You can check it with some textbooks like "operating Systems" by william stallings. Or look at the link below: macdesign.net/academic/it4813/it4813-Submitted/… – Aglimmer

Correct, the .NET Framework does not have a state called Blocked, although there are ways one can check to see if a particular lock or mutex is blocking a thread. – Blasted

My understanding of threads in Windows is that they are essentially the same as threads in the .NET Framework. To answer your (1), we are going to need to know in what way you believe "The thread lifecycle in the OS is not completely aligned with thread lifecycle in .NET framework" – Blasted

For example in windows we have a state called Started, which is not present in .net thread life cycle. Or the Blocked state in windows which I can not find an equivalent state in .net for it. Apart from that .net has some states which are not present in windows states like WaitSleepJoin. Aligning these kinds of states to its underling states in OS is a little bit tricky and I can't find a good resource for it. – Aglimmer

I think you might not be reading the MSDN documentation carefully. WaitSleepJoin is the "blocked" state, and the 'Started' state in Windows is called 'Running' in the .NET Framework. – Blasted

if they are the same, why 2 different states are designed for each of them in figure above ?? we both have Blocked and WaitSleepJoin. (the figure is from Deitel, C# how to program). Started is different from Running. They have different meaning. – Aglimmer

Blocked == WaitSleepJoin. Two different names, same thing. – Blasted

The albahari link mentions 'time-slicing' five times in the short 'How Threading Works' section - something that only happens often on a CPU-overloaded computer. There is nothing actually incorrect, but it's texts like this that give rise to common misconceptions and inappropriate, inefficient designs. When discussing thread states and scheduling, statements like 'Strictly speaking, the OS doesn't deal with threads; it deals with processes' don't help either. – Hormonal

@MartinJames: I removed that part of my answer. – Blasted

Over the years, I've been trying to think of some other term to replace 'time-slicing'. The only things I can come up with are 'interrupt-slicing' or 'event-slicing'. I think it's a losing battle - even Wikipedia lists under 'Premptive multitasking': 'guarantee each process a regular "slice" of operating time' before 'rapidly deal with important external events' :(( – Hormonal

Answer 2

Answers to your questions:

1. I don't believe this mapping would be as useful as you appear to hope. I've never run across one and never needed it.
2. There isn't a real need for a "Blocked" state unless you're trying to write something like a deadlock detector (rather advanced). From a typical developer perspective, the OS "blocked" state is transient and can be ignored. (It appears that your code is running, but the OS has nothing to do until the async response is received.)
3. Imagine the Aborted state as .NET providing an exception handler around all the code in the thread. When an exception is caught, causing the thread to die, .NET translates that to an Aborted state for you. Otherwise, you may not be able to tell the difference between abnormal and normal thread termination.

Rossuck

thank u. 1. I was reading OS books like "Operating systems" by stallings and he provides a diagram for thread state in different operating systems. I was curious to see what is the relation between what is .net framework is providing and what is really implemented in OS. You are right knowing this mapping is not so useful for developing softwares. 2.for example assume a thread is waiting for user input. In reality this thread is blocked by operating system until the user enters sth in console input, but the state of the thread is running ? – Aglimmer

3. Can u please check the Thread state section of this site. 'albahari.com/threading/part2.aspx#_ThreadState' what does he mean by in theory only!. – Aglimmer

Please check the figure in "Thread state" section. The transition from AbortRequested to Aborted. – Aglimmer

@ManiAm: Reading this section albahari.com/threading/part4.aspx#_Aborting_Threads should answer it. Basically, he's saying that the "Aborted" state doesnn't (or rarely) gets set. Instead, it shifts to "Stopped" when things are going well. – Rossuck