dale@amiga.UUCP (Dale Luck) (08/11/87)
After further consideration, the code to lower and raise the Priority may not be needed. As Brian Rhodefer pointed out, simply calling SetTaskPri with yourself and your current task priority may cause the corresponding Yield Affect.
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/11/87)
In some article, dale@amiga.UUCP (Dale Luck) pounded keys to produce: > > After further consideration, the code to lower and raise the Priority > may not be needed. As Brian Rhodefer pointed out, simply calling > SetTaskPri with yourself and your current task priority may cause > the corresponding Yield Affect. The effects would be different, though. If SetTaskPri() with my current priority flushes my quantum then drops me to then end of the round robin that's great. Yeild(), which droppped the priority for a moment would not work for a high (say 100) priority task wanting to be nice and give away a few cycles to low (say 0 to 4) priority tasks. If it dropped priority, it may not come back up (depending on load)! The mythical DumpQuantum() would just zone out for the rest of the quantum, after which normal tasking and priorities would rule. It would work well for a task that is about to do a long Forbid(), and wanted to be nice to other tasks and not abnormally pre-empt them. Again, though, a whole priority drop is rather severe. That task may wait >quite< a while if, say, some same priority CLI is typing a file. As I said, my application was oscure, and since it >required< the processor to come back in a certain number of miliseconds it would need a separate function anyway because the quantum period can't be guaranteed, and Disable() and Forbid() would mess with the scheme anyhow. Worse than Forbid() is, of course, FORBID, the macro. ----- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."