Hi!
On 19:52 Sun 09 Oct , Parmenides wrote:
> 2011/10/9 Daniel Baluta <[email protected]>:
> > On Sat, Oct 8, 2011 at 7:19 PM, Parmenides <[email protected]>
> > 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
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
