16

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:

enter image description here

  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?

ManiAm
  • 1,759
  • 5
  • 24
  • 43

2 Answers2

6

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/

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • 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: http://www.macdesign.net/academic/it4813/it4813-Submitted/IT4813-u03a1-Process_States.html – ManiAm Jan 23 '12 at 03:16
  • 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. – Robert Harvey Jan 23 '12 at 03:17
  • 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"* – Robert Harvey Jan 23 '12 at 03:20
  • 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. – ManiAm Jan 23 '12 at 03:28
  • 1
    I think you might not be reading the [MSDN documentation](http://msdn.microsoft.com/en-us/library/system.threading.threadstate.aspx) carefully. WaitSleepJoin *is* the "blocked" state, and the 'Started' state in Windows is called 'Running' in the .NET Framework. – Robert Harvey Jan 23 '12 at 03:37
  • 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. – ManiAm Jan 23 '12 at 03:43
  • Blocked == WaitSleepJoin. Two different names, same thing. – Robert Harvey Jan 23 '12 at 03:44
  • 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. – Martin James Jan 23 '12 at 10:10
  • @MartinJames: I removed that part of my answer. – Robert Harvey Jan 25 '12 at 18:03
  • 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' :(( – Martin James Jan 26 '12 at 16:18
3

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.
John Fisher
  • 22,355
  • 2
  • 39
  • 64
  • 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 ? – ManiAm Jan 26 '12 at 10:52
  • **3**. Can u please check the Thread state section of this site. 'http://www.albahari.com/threading/part2.aspx#_ThreadState' what does he mean by in _theory only!_. – ManiAm Jan 26 '12 at 10:53
  • Please check the figure in "Thread state" section. The transition from **AbortRequested** to **Aborted**. – ManiAm Jan 27 '12 at 08:10
  • @ManiAm: Reading this section http://www.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. – John Fisher Jan 27 '12 at 18:21