Hi! On 19:52 Sun 09 Oct , Parmenides wrote:
2011/10/9 Daniel Baluta <daniel.baluta@gmail.com>:
On Sat, Oct 8, 2011 at 7:19 PM, Parmenides <mobile.parmenides@gmail.com> 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