1) when is busy wait preferable to blockign wait?
and
2) In a multiprogramming system the execution context of a process (the registers, etc.) is
saved when the scheduler switches out one process and switches in a different process.
In a ‘uniprogramming’ system, there is one process in main memory. Are there
situations where the execution context of the process may have to be saved? Explain.
any help is greatly appreciated
Jump to Post1) I presume busy wait you mean the program displays something like the hourglass you see in browsers where the program continues to do something. The only purpose of the hourglass is to let the user know that the program is doing something that may take some time to complete. …
1) I presume busy wait you mean the program displays something like the hourglass you see in browsers where the program continues to do something. The only purpose of the hourglass is to let the user know that the program is doing something that may take some time to complete. The block wait is like the message "Press any key to continue", where the program is actually stopped until you press a key to make it continue. When to use which one all depends on the program and what you the programmer want it to do.
2: >>Are there situations where the execution context of the process may have to be saved
MS-DOS 6.X and older is considerded a "uniprogramming system". The answer is yes because it too has hardware and software interrupts which, as its name implies, interrupts the execution of the main program for a little while to do something else, then when done the interrupt handler will return resume the main program where it left off. This is not a scheduled task switch as it is in multi-programming enviroments such as *nix and MS-Windows.
hey thanks for the help...thats kind of what i figured about the interrupts. as far as the busy wait vs. blocking wait that kind of makes sense. i know busy waits are preferable for tasks that don't take that long to execute. thanks again for your help
Ancient Dragon's first answer seems rather completely wrong. 'Busy waiting' is where a computer checks for input over and over again in a loop. I.e. something that looks like this:
while (eventsPending() == 0) {
}
e = nextEvent();It is never good to busy wait when a blocking solution is available, since your process will eat up the CPU while busywaiting. It makes much more sense to make a blocking call, because then the kernel can allocate CPU time to other processes. It might make sense to make a non-blocking call if you want your program to do other things in the meantime. I'd rather use threads for that purpose.
>>Ancient Dragon's first answer seems rather completely wrong
Possible, depending on the definition of "busy waiting". Using your definition I might just check the keyboard for input
while( !kbhit() )
{
// do some processing
}I agree with you that coding an empty function like the one you posted is a horrible thing to do because it consumes too much CPU time.
I agree that busy wait is not good, but I could think of one rare situation that a process wants to busy wait instead of blocking:
When a process greedily wants to capture an event as soon as possible, so that it probably would not like to give its CPU time slicing away!
But this situation must happens in a multi-processor/multi-core environment, that is, there are two or more processes can run concurrently; otherwise, busy wait totally makes no sense.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.