process states ps vs. Andrew Tanenbaum

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
ggodw000
Member
Member
Posts: 396
Joined: Wed Nov 18, 2015 3:04 pm
Location: San Jose San Francisco Bay Area
Contact:

process states ps vs. Andrew Tanenbaum

Post by ggodw000 »

I am studying the minix processes section of Andrew Tanenbaum's OS design and implementation book. There the topic of processes progresses into mutex and semaphores and describes process having state of
- running
- block
- sleep
Now it is academic book and not as complicated as real-life scenario.

But on "man ps" the process has about 9 states. Not sure how some of above three maps into below:
I am assuming:
- running -> R running or runnables
- block -> Not sure on this one???
- sleep -> S interruptable sleep.

PROCESS STATE CODES top
Here are the different values that the s, stat and state output
specifiers (header "STAT" or "S") will display to describe the state
of a process:

D uninterruptible sleep (usually IO)
I Idle kernel thread
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by
its parent
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
alexfru
Member
Member
Posts: 1111
Joined: Tue Mar 04, 2014 5:27 am

Re: process states ps vs. Andrew Tanenbaum

Post by alexfru »

I don't have the original (1st ed) MINIX book handy, but in others that I can peek, the process states listed (at the beginning of the processes chapter) are a bit different:
  • running
  • ready
  • blocked
nullplan
Member
Member
Posts: 1769
Joined: Wed Aug 30, 2017 8:24 am

Re: process states ps vs. Andrew Tanenbaum

Post by nullplan »

ggodw000 wrote: D uninterruptible sleep (usually IO)
I Idle kernel thread
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent
I think you are right with your mapping. Additionally, D, T, t, and W merely denote specializations of being blocked, and I appears to be a special kernel-mode sleep state. X and Z denote garbage someone has yet to clean up, not a real process.
Carpe diem!
ggodw000
Member
Member
Posts: 396
Joined: Wed Nov 18, 2015 3:04 pm
Location: San Jose San Francisco Bay Area
Contact:

Re: process states ps vs. Andrew Tanenbaum

Post by ggodw000 »

it is getting quickly confusing.
Looked up number of sites, each has different terms:
So far https://www.tutorialspoint.com/operatin ... duling.htm has good explanation in regards to
job scheduler (long term scheduler), CPU scheduler (I assume it is task scheduler or context switching) and then describes about different types of queue.
Ready queue is all processes residing in main memory whereas job queue is managed by job scheduler apparently.

By definition from https://wiki.osdev.org/Blocking_Process:
Blocking - state of wait, waiting for event i.e. semaphore released. Not in active scheduling queue.
Sleep - Process is set inactive for period of time (i.e. 20ms) while in a sleeping queue.

Now there is an "active scheduling queue" vs. ready queue, I am assuming they are same.
In the definition of sleep, there is a "sleeping queue" mentioned.

This link also had good explanation, but mentions about runqueue:
http://www.informit.com/articles/articl ... 0&seqNum=2

:roll: :roll:
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
Post Reply