[LITMUS^RT] Question about the RT_F_XXX flags

[Björn Brandenburg]

On Oct 1, 2012, at 10:43 PM, John Gamboa wrote:

> 2012/10/1 Jonathan Herman <hermanjl at cs.unc.edu>
> Hi John,
> 
> Hi. Thanks for the quick answer!
> 
> There is some term overloading going on here which causes confusion.
> The is_running() macro does not refer to RT_F_RUNNING, nor is the
> task_wake_up() call invoked when a task should go from RT_F_SLEEP to
> RUNNING. RT_F_SLEEP is unrelated to blocking / waking up from
> blocking.
> 
> As I see it, RT_F_SLEEP refers to tasks which should not be run
> because they have completed their current job. Its only purpose is to
> allow the complete_job() method (called from userspace) to mark a job
> as "completed". This way, the subsequent call to psn_edf_schedule()
> can prepare the job for its next period and arm any appropriate
> timers.

Exactly, RT_F_RUNNING is a remnant  from the very first version of Litmus (2006 era). The only use is to signal to the scheduling function that a job completion has occurred. It's not very elegant and terribly misnamed (it really has nothing to do with actual suspensions/wakeups), but I guess nobody ever got around to renaming it…

> Yes. I see it. That's why I suggested (or, actually, was expecting) some flags for "blocked" and "woken up", which would be set at task_block() and task_wake_up(), respectively. Then I could test if a task is running and blocked with something like "get_rt_flags(t) == (RT_F_RUNNING | RT_F_BLOCKED)".
> 
> Although I feel that creating these flags (say, "RT_F_BLOCKED" and "RT_F_WOKEN_UP") there in my code wouldn't create any mess, I believe that the code is the way it is now for some reason. Supposing that a possible reason could be: the Linux kernel already provides a way to verify if a task is blocked or woken up (at least, for me, it is what is seems), then should I consider the "is_running()" macro the "right" way to verify it? (i.e., is there any case in which it won't work?)

is_running() is the right macro to use. It uses Linux's task state, which is the authoritative source on whether it is safe to execute a given task nor not. Adding new RT_F_xxxx flags is likely going to cause much debugging trouble. Instead, it would be much better to get rid of the RT_F_ thing entirely.

- Björn