Hi! On 19:52 Sun 09 Oct , Parmenides wrote: > 2011/10/9 Daniel Baluta <daniel.baluta@xxxxxxxxx>: > > On Sat, Oct 8, 2011 at 7:19 PM, Parmenides <mobile.parmenides@xxxxxxxxx> wrote: > > > > Well, I think that if task B has higher priority than task A, then A would > > never have the chance to release the lock. > > > > Hmm...! Does that mean lower priority tasks never have chances to run > when a highest priority task is running? AFAIK, for the old O(1) > scheduler, even with higher priority, B eventually will be put into > expire array when it using up its timeslice. That cause A has chance > to run again. As far as the newer CFS scheduler is concerned, when > B's virtual clock is go ahead prior to A, the the scheduler might also > select A to run again. So, I think A can release the spin lock > eventually. This is true for "normal" priorities. For real time tasks this is different: The kernel always runs the task with the highest priority. However, a few years ago, a throttle mechanism was implemented because real time tasks occasionally locked up the system. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
