Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Your Opinion of REBOL ???
Message
From
31/01/2000 14:58:51
Walter Meester
HoogkarspelNetherlands
 
 
To
30/01/2000 22:55:05
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00324501
Message ID:
00325244
Views:
31
Jim,

From the Operation systems concents written by A.silberschats universaty of Texas, P. Galvin. Brown Universaty. ISBN 0-201-59292-4


Preemptive scheduling:

CPU scheduling decisions may take place under the following curcumstances:

1.When a process switches from the running state to the waiting state (for example, I.o request, or invocation of wait for the termination of one of the child processes)

2. When a process switches from the running state to the ready state (for example when an interupt occurs) 'This is certainly implicit'

3. When a process switches from the waiting state to the ready state (for example, completion of I/O) 'So when the I/O is done the ready state is invoked to let the CPU handle the result'

4. When a process terminates

When scheduling takes place only under circumstances 1 and 4, we say the scheduling scheme is nonpreemptive, otherwise it is preemptive.

You seem to be correct here. Scheduling in a preemptive environment is MUCH more than time-slicing and vulontary enter WAIT states.

Walter,



>Ed,
>
>If the line above was aimed at me it was totally uncalled-for!@#!@#@!
>
>And to clarify further... with reference to MFT/MVT/SVS/MVS and other "mainframe" operating systems (VM/CMS, DOS, DOS/VSE), 99%+ of the programming did not perform/invoke a "voluntary" WAIT - programs were coded 'straight through', as if there was no such a thing as a "wait". In other words the programming was *not* coded as:
>
>- READ a record
>- WAIT
>- process that record
>
>but rather as
>
>- READ a record
>- process that record
>
>The 'wait' happened (or not) within the O/S code "servicing" the I/O (READ in this case) and if a WAIT were necessary then the dispatcher took over and set the next "ready" task (back to) processing.
>
>There are other factors too, like priority of tasks, and a higher priority task that becomes ready *would* (via the dispatcher), pull the rug right out from the currently processing task *regardless* of slice time left or anything else. Same goes for timer pops.
>
>In other words, in those operating systems, preemptive really was preemptive and involved much more than just time slice expirations.
>
>Your propensity to directly or slyly slide in insults is becoming tiresome. Feel free not to respond at all if you feel that such useless commentary is warranted.
>
>Regards,
>
>Jim N
Previous
Reply
Map
View

Click here to load this message in the networking platform