Hello,
For your information: I have found that 'rt_post_taskswitch' is not invoked every task switch when using round-robin scheduling - only if tasks physically give up their time slice (by waiting, trying to lock a mutex, etc.). I have created a test program to reproduce this problem and informed Keil support about it.
Tamir
Are you saying that there are cases that you would like rt_post_taskswitch to be called when no task switch actaully takes place?
I might be wrong (I have been at least once before) that if a time slice expires, even if a task switch occurs - rt_post_task_switch will not be called.
It only gets called if os_dispatch()(which calls os_switch_task(), the timer tick bypasses this call)
It would be very easy to have it ALWAYS call rt_post_task_switch when the time slice expires, but I think that is very wrong if no task switch actaully happens. We will see what they come up with.
Robert,
Thanks for your reply. I only want the function to be invoked when an actual context switch occurs. I have sent a program to technical support which clearly demonstrate that it is not; tasks are switched - a scope and breakpoints prove that - but 'rt_post_taskswitch' is called only twice, probably after the tasks are created (the program contains two tasks). I can install calls to 'os_tsk_pass' to cause it to be invoked, though.
You wrote:
It would be very easy to have it ALWAYS call rt_post_task_switch when the time slice expires, but I think that is very wrong if no task switch actaully happens.
I agree. If the scheduler chooses the same task again, then I agree that the function does not have to be invoked. But the current behavior makes it impossible to a client to evaluate some aspects of our product, unless I litter the program with 'os_tsk_pass' etc. or reduce the measurement accuracy by placing the measurement code in the tasks themselves.
We will see what they come up with.
I don't think it will be TOO hard to make it right, but as you have said, it needs to be called on time slice initiated task switches when using Round Robin - which it does not appear to do and NOT call just because the time slice expired.
Actually there is no problem. The rt_post_taskswitch is not a public function. It is used internally by RT Agent to track the task switching for RTX debug dialog in uVision. For this purpose it works just fine.
Hello Franc,
Thanks for your reply. If this is the case, how can the RT agent ever report correct program behavior? When one create empty tasks, like these:
__task void task1(void) { for(;;) { } } __task void task2(void) { for(;;) { } }
the function is not invoked (thus RT agent is not informed about a task switch), unless 'os_tsk_pass()' is called by the tasks. Is this really desired behavior?
It does work fine if it is called at the proper times. But it is not always called at the proper times.
The RT Agent NEVER detects a task switch caused by round robin timeout.
Because of this, the RT Agent does not track task switching properly for the RTX debug dialog in uVision.
You are 100% correct - no less. I have also noticed that the RT agent does not always function properly, even in Keil's samples! If that is the case, why is this still considered as correct behavior by Franc? I really don't understand where this is heading (other than me having to adjust the kernel myself...). Franc: Please advise.
Keil support have promised to address this issue in the next RL-ARM update.
I have received updated libraries from Keil. The RT agent works! It really does, and my scope draws the correct waveform for empty tasks being preempted, too. Thanks a lot for the efforts.
View all questions in Keil forum