Bosko Radivojevic wrote:
> Are there any differences (in performance point of view) between using
> rt_task_sleep_until (TM_INFINITE) + rt_task_unblock() and
> rt_task_suspend() + rt_task_resume() ? I'm writting some kind of task
> manager and I'm using suspend + resume combination.
>
Internally, this boils down to running the same code.
> On Wed, Apr 23, 2008 at 1:37 PM, Philippe Gerum <[EMAIL PROTECTED]> wrote:
>> Klaas Gadeyne wrote:
>> > On Tue, 22 Apr 2008, Philippe Gerum wrote:
>> >
>> > [snipping even more context]
>> >
>> >>>> What's wrong with rt_task_suspend() ?
>> >>>
>> >>> The current loop code is something like
>> >>>
>> >>> void timerloop_task_proc(void *arg)
>> >>> {
>> >>> int ret;
>> >>> int errors = 0;
>> >>> do{
>> >>> do{
>> >>> last_occured_alarm = last_alarm_set;
>> >>> EnterMutex();
>> >>> TimeDispatch();
>> >>> LeaveMutex();
>> >>> }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>> >>> if (ret == -ETIMEDOUT){
>> >>> printf("[TIMERLOOP] Total errors = %d, return code =
>> >>> %d\n",++errors,ret);
>> >>> }
>> >>> }while (!(stop_timer && ret == -EINTR));
>> >>> printf("End of TimerLoop, code %d, Total errors =
>> >>> %d\n",ret,errors);
>> >>> }
>> >>>
>> >>> I could modify that code and put something like
>> >>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>> >>> rt_task_suspend()
>> >>> else
>> >>> rt_task_sleep_until(last_alarm)
>> >>>
>> >>> However, the one who wants to wake up this thread (e.g. for asking
>> >>> this thread to stop) doesn't know in what state the timerthread is.
>> >>> It seems clumsy to me if that the one who wants to wake up the thread
>> >>> has to try _unblock() first, and the _resume()?
>> >>>
>> >>
>> >> There has been a fair amount of misunderstanding. Past mails were
>> >> apparently
>> >> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay
>> >> etc.), but
>> >> you actually care for rt_task_sleep_until, which is a totally
>> >> different story
>> >> (the subject line was right though).
>> >
>> > Sorry about that, during the debugging I ended up playing around with
>> > rt_task_sleep() to check if the overflow issues did occur there too.
>> >
>> >> Handling the special TM_INFINITE value as a valid timeout value for
>> >> rt_task_sleep_until would not introduce the flaws I was concerned about
>> >> regarding rt_task_sleep. We would just change the behaviour when
>> >> receiving what
>> >> used to be an utterly bugous date spec in the current implementation,
>> >> and make
>> >> it valid, which is ok -- i.e. I'm not particularly concerned by
>> >> maintaining
>> >> backward compatible behaviours when receiving utterly insane data
>> >> specs like "0"
>> >> for an absolute date.
>> >>
>> >> If your loop was truly periodic, you could probably use
>> >> rt_task_wait_period(),
>> >> but I suspect last_alarm may not try to enforce a strictly periodic
>> >> timeline, right?
>> >>
>> >> The fact that we don't have any other blocking calls with absolute
>> >> date specs is
>> >> bothering me actually, and 2.5 will probably see some extensions like
>> >> rt_sem_p_until(), in order to address patterns of this kind.
>> >>
>> >> But well, back to rt_task_sleep_until, I see no reason not to handle
>> >> the corner
>> >> case you described a bit more gracefully. So let's try the Klaas
>> >> Amendment to
>> >> the native API.
>> >
>> > I *really* like the way that sounds ;-)
>> >
>> >> Does the following work for you?
>> >
>> > [snipped patch]
>> >
>> > It does! Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03
>> kernel.
>> > Any chance this could still be merged in the 2.4 series?
>> >
>>
>> Since this does not change the behaviour of documented and valid use cases,
>> I
>> will merge that patch into 2.4.4.
>>
>> > Thx for your patience!
>> >
>>
>> You are welcome.
>>
>> > Klaas
>> >
>> >
>>
>>
>> --
>> Philippe.
>>
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> [email protected]
>> https://mail.gna.org/listinfo/xenomai-help
>>
>
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
