Hi, list

I'm trying to get some overview understanding about this process. I know
it's very complicated and you can hardly find any good documents or books on
this topic so simplification is used in my endeavour.

My starting point is when the TCB is selected by dispatcher to execute.
Dispatcher will set the status using PSW and register areas in TCB/STCB.
After that CPU will be executing instructions of my program.

It's obvious that my TCB can hardly have the chance to occupy CPU
exclusively until it terminates because there're many other dispatch units
who need to be served too. The question is how that happens.

>From what I know, interrupt is the only way. When interrupt occurs, my TCB
will lose control and after interrupt handling (FLIH, SLIH..etc) control
will be given to dispatcher and it'll select the next dispatched unit using
its algorithm.

I know execution of my program will usually generate interrupts, for
example, I/O interrupt or page-fault. But will the system solely depend on
that? In an extreme case, my program will not lead to any interrupt and will
it eat all CPU cycles?

Searching the old posts I learned that there are at least two cases when
interrupts will be generated regardless of my programs' behaviour:

1. SRM will be invoked routinely via clock comparator interrupt.

2. Each dispatch unit will have a time slice and when it expires a CPU timer
interrupt occurs.

Using the above two methods, dispatcher will be invoked even if my program
doesn't do it 'voluntarily'. Thus other dispatch units will have the chance
to be served.

However, if my program is also running disabled for external interrupts and
it uses CPU cycles heavily , how will the system 'pre-empt' my TCB? Or it
cannot and just let my TCB starve other users? I cannot figure out.

-- 
Best Regards,
Johnny Luo

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to