Author Topic: Process state  (Read 5384 times)

0 Members and 1 Guest are viewing this topic.

Offline BlogRahulTopic starter

  • Regular Contributor
  • *
  • Posts: 75
  • Country: in
Process state
« on: February 15, 2022, 02:01:50 pm »

What's the best to understand discription given on Wikipedia   https://en.wikipedia.org/wiki/Process_state for Process state. Page does not provide enough information. I am having difficulty understanding Process state and need an practical example to clarify the definition.


Ready : Ready tasks are those that are able to execute but are not currently executing on the CPU.

Running : When a task is actually executing it is said to be in the Running state. It is currently utilising the CPU.

Blocked : A task is said to be in the Blocked state if it is currently waiting for external event.

Can anyone clarify how the process state concepts are applied to a project ?
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 10091
  • Country: us
Re: Process state
« Reply #1 on: February 15, 2022, 02:54:59 pm »
Process State comes up whenever we have some kind of time-sharing of a CPU.  Perhaps we have an RTOS (Real Time Operating System) responsible for scheduling several tasks.  For most uCs, only a single task is running at any given instant.  That task is 'Running'.

The other tasks are not Running but there are two possibilities:  A task could be Ready to run and waiting on a task switch or the task may be Blocked because it is waiting on an event to occur which will cause it to become ready.  Perhaps a serial port handler where the task stays Blocked until an interrupt occurs as a result of receiving a character.  A Ready task may be delayed due to priority, the Running task has a higher priority so it gets the CPU time.

At each time tick, the scheduler looks through the list of Ready tasks and starts the one with the highest priority.  It also marks the previous Running task as Ready.  It could be that the Running task is the highest priority (it was a 'tick' ago) and it gets restarted.  This can cause hogging of resources and needs to be dealt with.
« Last Edit: February 15, 2022, 03:02:17 pm by rstofer »
 
The following users thanked this post: BlogRahul

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11370
  • Country: fi
Re: Process state
« Reply #2 on: February 15, 2022, 02:57:09 pm »
applied to a project ?

Project, what project? Are you designing an Operating System? Going deep down in OS internals for some other reason? Or are you just writing a normal userspace program? What kind of program? Or is this just homework?
 
The following users thanked this post: BlogRahul

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 10091
  • Country: us
Re: Process state
« Reply #3 on: February 15, 2022, 03:10:01 pm »
Here is a page discussing a "super loop" which is a poor alternative to an RTOS.  At the bottom of the page is a link to Solution 2 which cleans things up by using an RTOS to schedule the work.

https://www.freertos.org/tutorial/solution1.html

Follow along further if you have interest in the topic of scheduling.
 
The following users thanked this post: BlogRahul

Offline BlogRahulTopic starter

  • Regular Contributor
  • *
  • Posts: 75
  • Country: in
Re: Process state
« Reply #4 on: February 15, 2022, 03:41:28 pm »
applied to a project ?

Project, what project? Are you designing an Operating System? Going deep down in OS internals for some other reason? Or are you just writing a normal userspace program? What kind of program? Or is this just homework?

I am not going to design an Operating System. I am looking practiacl example to clerify the defination given on on Wikipedia. I want to understand How the concepts of process state are applied for any  project.  I guess process state come into the role when application program is written
 

Offline BlogRahulTopic starter

  • Regular Contributor
  • *
  • Posts: 75
  • Country: in
Re: Process state
« Reply #5 on: February 15, 2022, 03:46:49 pm »
Here is a page discussing a "super loop" which is a poor alternative to an RTOS.  At the bottom of the page is a link to Solution 2 which cleans things up by using an RTOS to schedule the work.

https://www.freertos.org/tutorial/solution1.html

Follow along further if you have interest in the topic of scheduling.

I find this bit interesting but I don't understand in context of process state given on  Wikipedia.

 Can you demonstrate example ?
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1811
  • Country: us
Re: Process state
« Reply #6 on: February 15, 2022, 04:12:15 pm »
I am not going to design an Operating System. I am looking practiacl example to clerify the defination given on on Wikipedia. I want to understand How the concepts of process state are applied for any  project.  I guess process state come into the role when application program is written

When using something like an RTOS, you really don't need to be concerned about how the RTOS manages processes (and what states they're in at any given time). Generally, the only thing you typically need to be concerned about are the relative priorities of the processes in your application. You assign priorities to processes depending on their need for CPU time, responsiveness to events, etc., and let the RTOS handle the rest. There are ways to assign process priorities, Rate-monotonic Scheduling, for example, but that's an advanced concept and isn't needed for many real-time systems.
"That's not even wrong" -- Wolfgang Pauli
 
The following users thanked this post: BlogRahul

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 10091
  • Country: us
Re: Process state
« Reply #7 on: February 15, 2022, 04:20:43 pm »
The full Wiki definition applies to operating systems.  There are simply too many states for a simple 'project'.  Swapping out is an example but it assumes a Memory Management Unit to control what is located where in memory and, in fact, whether the code is even in memory (still or yet).

Your original question was about just 3 process states and that's pretty easy.  You could write a serial IO interrupt handler that takes characters from the receiver and stuffs them in a circular queue as a result of an interrupt.  It then posts a flag that the queue has data.  The scheduler, however it is done, tests the flag and calls the code that processes the queued data.  There is no point in calling code just to find out that data isn't available when the interrupt handler can post a flag that there IS data.

The interrupt handler probably exists outside the RTOS span of control (it likely won't be scheduled in any way) and the serial input task waits on a semaphore from the interrupt handler.  The scheduler notices the semaphore (flag) and schedules the queue handler.  That may, or may not, be the highest priority task.  I suppose it could vary as the queue fills up.  One char - no hurry, 127 chars filled in a 128 char buffer, better get to it.

Solution 2 deserves a lot of attention because it is a common chunk of code for uCs that don't have a formal OS (like Linux or Windows).  You simply wouldn't have the resources in a small uC to implement a complete OS.  Nevertheless, the Raspberry PI (among others) does run a complete OS on a high end uC.

Even if an RTOS isn't strictly necessary, it provides a mechanism for segmenting the project.  Individual tasks do their own thing without worrying about what some other task is doing.  This makes the project easier to create and maintain.

« Last Edit: February 15, 2022, 04:47:44 pm by rstofer »
 
The following users thanked this post: BlogRahul

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11370
  • Country: fi
Re: Process state
« Reply #8 on: February 15, 2022, 04:23:42 pm »
I am not going to design an Operating System. I am looking practiacl example to clerify the defination given on on Wikipedia. I want to understand How the concepts of process state are applied for any  project.  I guess process state come into the role when application program is written

Well, the answer is, usually application programs do not have any idea about the process state. There might be special cases, like if you application is a process monitor (the purpose of which is to show these states!).

Process state is an OS internal. Your own application is typically just one process; it runs and exists. Sometimes you might want to fork other processes, but even then, they would just normally run and exit, without your code ever looking at their state.
 
The following users thanked this post: agehall, BlogRahul

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4668
  • Country: us
Re: Process state
« Reply #9 on: February 15, 2022, 10:35:01 pm »
Let's say your project read commands from the serial port, and writes sequences to a sting of neopixel smart LEDs.It accepts command "red", "green", "blue" and sets the color appropriately.

If you haven't sent anything to the serial port, your application is "blocked" - it is waiting for external things to happen.
If you have sent a "red" command, there will be a brief time when the app is "ready" but hasn't actually started doing anything yet.   It is "Ready" - everything it needs is there, but it hasn't gotten around to it yet.
Finally, the application will begin processing your command, and manipulating the LEDs.  It is "running."

 
The following users thanked this post: bill_c, BlogRahul

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4668
  • Country: us
Re: Process state
« Reply #10 on: February 15, 2022, 10:48:09 pm »
It's usually especially obvious in a timesharing/mainframe context.  Consider a box with 100 users running business programs.
Some of them will be waiting for IO (from terminals, from disks, etc.)  Blocked.
Some of them will be doing math.  Running.
Some of them will only be waiting for one of the 100 other users to do their math.  Ready.
The power of timesharing is that IO is usually very slow compared to the CPU, so there are typically a lot of users "blocked", that don't care at all whether another user is doing math.

The "Load Average" that measures the "busy-ness" of such a system is usually based on the number of users in "ready" state - users who could be doing math, but aren't "running" because some other user is running.

It gets more obscure when a system has all sorts of tiny processes that aren't so obviously distinct.  A web browser application on a desktop will have "many" processes, and it's harder to figure out which ones are dependent on what.
 
The following users thanked this post: BlogRahul

Offline BlogRahulTopic starter

  • Regular Contributor
  • *
  • Posts: 75
  • Country: in
Re: Process state
« Reply #11 on: February 16, 2022, 12:13:36 pm »
suppose we have two tasks T1 and T2 ready to run
T1 is highest priority task
T1 must be finished every 100us time interveral
If T1 is not finished within 100us then we lose data. It should be finished within 100us

T1 takes 10us time of CPU  to finish job

We have 90us of CPU time we can use of T2

T1 keeps the control of CPU up to 10 us so we call it running state of T1

My question is, which state T1 goes after 10 us. I think T1 should go in blocking state of task. Does it go into blocking state 90 us ?   
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 10091
  • Country: us
Re: Process state
« Reply #12 on: February 16, 2022, 05:55:19 pm »
You have the right idea but the wrong time scale, in my opinion.  For FreeRTOS, the tick rate is usually around 1 kHz or 1 ms.  You can't use the RTOS tick for timing at the 10 us level.  In fact, you pull most of T1 out of the RTOS control and drive it with a timer interrupt.  If T1 generates data for a task under FreeRTOS' control, you have to be prepared to queue some of it at the interrupt driver level and fetch it at a future RTOS timer tick.

You can Google for 'FreeRTOS tick rate' for more information.

It really depends on the complexity of the application whether to even get involved with an RTOS.  Sometimes you just have to do your own scheduling and work things out with interrupts and interrupt priority.

If there are only a couple of tasks, timer interrupts may work perfectly.  T2 has control at all times except when T1 responds to an interrupt.
« Last Edit: February 16, 2022, 05:57:32 pm by rstofer »
 

Offline eugene

  • Frequent Contributor
  • **
  • Posts: 602
  • Country: us
Re: Process state
« Reply #13 on: February 16, 2022, 06:12:09 pm »

What's the best to understand discription given on Wikipedia   https://en.wikipedia.org/wiki/Process_state for Process state. Page does not provide enough information. I am having difficulty understanding Process state and need an practical example to clarify the definition.


Ready : Ready tasks are those that are able to execute but are not currently executing on the CPU.

Running : When a task is actually executing it is said to be in the Running state. It is currently utilising the CPU.

Blocked : A task is said to be in the Blocked state if it is currently waiting for external event.

I think the wiki page is pretty clearly written. Perhaps you missed the first line "In a multitasking computer system, processes may occupy a variety of states." With the emphasis being mine?

Quote
Can anyone clarify how the process state concepts are applied to a project ?

Is your project running on a multitasking operating system?
90% of quoted statistics are fictional
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

- - -
-->