[LITMUS^RT] non preemption and unlink()ing

Björn Brandenburg bbb at mpi-sws.org
Wed Feb 5 09:03:42 CET 2014


On 17 Jan 2014, at 09:02, Björn Brandenburg <bbb at mpi-sws.org> wrote:

> On 17 Jan 2014, at 03:09, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> 
>> Why do we unlink() even if the scheduled task (entry->scheduled) will remain running?  I have tasks that, upon exiting a non-preemptive section, are descheduled and are never rescheduled.  I think they fell off a queue some where.
> 
> A task that is unlinked should be put back into the ready queue (assuming it is still runnable). Since preempt=1 in your example, the scheduled task is no longer linked and hence should already be in the ready queue. But it is then removed from the ready queue because of the call to unlink() from schedule.
> 
> Calling unlinked on entry->scheduled again seems wrong, at least in this case. It still seems appropriate for the sleep=1 and out_of_time=1 cases. I'm surprised this didn't cause problems before. I guess you actually need a lot of non-preemptable sections within a certain length range to hit this case reliably. If the NP task is relinked before the core schedules or if the core never schedules, it won't cause a problem.
> 
>> Do we need to call job_arrival() on the job exiting the non-preemption section?
> 
> No, I think that would be the wrong workaround. Not calling unlink() should do the trick.
> 
> Could you please add a simple test case for this to the liblitmus test suite? I'd like to reproduce this locally.

Hi Glenn,

has this been resolved? If not, I would still appreciate a test case so that I can investigate the problem here as well.

Thanks,
Björn





More information about the litmus-dev mailing list