How a periodic task is handled?

bridged with qdn.public.devtools
Post Reply
John Zou

How a periodic task is handled?

Post by John Zou » Tue Oct 28, 2003 4:52 pm

Hi everyone,

I want to create a task that runs once every 2.5ms. Can anyone tell me by
what calling can I make this?
I've read the documentation on the timer_create() and timer_settime(), Is
these functions the best solution to my question? If so, please paste an
example, thanks!

Mario Charest

Re: How a periodic task is handled?

Post by Mario Charest » Tue Oct 28, 2003 11:29 pm

"John Zou" <yjzou@sina.com> wrote in message
news:bnm5ro$gh0$1@inn.qnx.com...
Hi everyone,

I want to create a task that runs once every 2.5ms. Can anyone tell me by
what calling can I make this?
I've read the documentation on the timer_create() and timer_settime(), Is
these functions the best solution to my question? If so, please paste an
example, thanks!
Paste and example, you want it easy don't you, lol!

Yeah setup timer to fire a pulse ever 2.5 (and don't forget to set tick size
to 500us via ClockPeriod() )

Your program sit in the receive loop and will get waken up every 2.5 ms,
there should be enough information/example in the online-help to get to
where you want to be.





Bill Caroselli

Re: How a periodic task is handled?

Post by Bill Caroselli » Wed Oct 29, 2003 1:19 pm

Mario Charest <postmaster@127.0.0.1> wrote:

MC > "John Zou" <yjzou@sina.com> wrote in message
MC > news:bnm5ro$gh0$1@inn.qnx.com...
Hi everyone,

I want to create a task that runs once every 2.5ms. Can anyone tell me by
what calling can I make this?
I've read the documentation on the timer_create() and timer_settime(), Is
these functions the best solution to my question? If so, please paste an
example, thanks!
MC > Paste and example, you want it easy don't you, lol!

MC > Yeah setup timer to fire a pulse ever 2.5 (and don't forget to set tick size
MC > to 500us via ClockPeriod() )

MC > Your program sit in the receive loop and will get waken up every 2.5 ms,
MC > there should be enough information/example in the online-help to get to
MC > where you want to be.

This example is cut from the helpviewer page for TimerCreate().
Syudy it and make the necessary changes to suit your needs.

----------------------

/*
* Demonstrate how to set up a timer that, on expiry,
* sends us a pulse. This example sets the first
* expiry to 1.5 seconds and the repetition interval
* to 1.5 seconds.
*/

#include <stdio.h>
#include <time.h>
#include <sys/netmgr.h>
#include <sys/neutrino.h>

#define MY_PULSE_CODE _PULSE_CODE_MINAVAIL

typedef union {
struct _pulse pulse;
/* your other message structures would go
here too */
} my_message_t;

main()
{
struct sigevent event;
struct itimerspec itime;
timer_t timer_id;
int chid;
int rcvid;
my_message_t msg;

chid = ChannelCreate(0);

event.sigev_notify = SIGEV_PULSE;
event.sigev_coid = ConnectAttach(ND_LOCAL_NODE, 0,
chid,
_NTO_SIDE_CHANNEL, 0);
event.sigev_priority = getprio(0);
event.sigev_code = MY_PULSE_CODE;
timer_create(CLOCK_REALTIME, &event, &timer_id);

itime.it_value.tv_sec = 1;
/* 500 million nsecs = .5 secs */
itime.it_value.tv_nsec = 500000000;
itime.it_interval.tv_sec = 1;
/* 500 million nsecs = .5 secs */
itime.it_interval.tv_nsec = 500000000;
timer_settime(timer_id, 0, &itime, NULL);

/*
* As of the timer_settime(), we will receive our pulse
* in 1.5 seconds (the itime.it_value) and every 1.5
* seconds thereafter (the itime.it_interval)
*/

for (;;) {
rcvid = MsgReceive(chid, &msg, sizeof(msg), NULL);
if (rcvid == 0) { /* we got a pulse */
if (msg.pulse.code == MY_PULSE_CODE) {
printf("we got a pulse from our timer\n");
} /* else other pulses ... */
} /* else other messages ... */
}
}

Bill Caroselli

Re: How a periodic task is handled?

Post by Bill Caroselli » Wed Oct 29, 2003 1:20 pm

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Mario Charest <postmaster@127.0.0.1> wrote:

BC > MC > "John Zou" <yjzou@sina.com> wrote in message
BC > MC > news:bnm5ro$gh0$1@inn.qnx.com...
Hi everyone,

I want to create a task that runs once every 2.5ms. Can anyone tell me by
what calling can I make this?
I've read the documentation on the timer_create() and timer_settime(), Is
these functions the best solution to my question? If so, please paste an
example, thanks!
BC > MC > Paste and example, you want it easy don't you, lol!

BC > MC > Yeah setup timer to fire a pulse ever 2.5 (and don't forget to set tick size
BC > MC > to 500us via ClockPeriod() )

BC > MC > Your program sit in the receive loop and will get waken up every 2.5 ms,
BC > MC > there should be enough information/example in the online-help to get to
BC > MC > where you want to be.

BC > This example is cut from the helpviewer page for TimerCreate().
BC > Syudy it and make the necessary changes to suit your needs.
^^^^^
Study

Guest

Re: How a periodic task is handled?

Post by Guest » Wed Oct 29, 2003 4:13 pm

Bill Caroselli wrote:
This example is cut from the helpviewer page for TimerCreate().
Syudy it and make the necessary changes to suit your needs.

----------------------

/*
* Demonstrate how to set up a timer that, on expiry,
* sends us a pulse. This example sets the first
* expiry to 1.5 seconds and the repetition interval
* to 1.5 seconds.
*/

#include <stdio.h
....

Something like this would be quite useful.
It's similar to hooking an interrupt service routine
to a hardware timer.

I guess the same thing can be done with a thread,
and setting up the timer yourself, but a convenience
function call would be useful. One would also
need to change the priority of the new thread to
get the same effect of a interrupt service routine.

This type of functionality is useful if you have
1 or more function which needs to be called every interval
without fail, and you don't have a hardware timer
to hook it to.

In this case, the TimerCreate function will not
do depending on what else is going on in the
main's MsgReceive loop.

Jan Rüdiger

Re: How a periodic task is handled?

Post by Jan Rüdiger » Fri Oct 31, 2003 10:42 am

Hi

We are sitting here on the same problem. Timer works great if you have
only a few. But we have one Programm starting a lot of thread. Each
thread gets a different priority and some a fifo. Our Problem now that
we don'T know under which priority the timers run. Do they have the same
as the father prog? also the don't show up in pidin?

Our Workaround are timers that wake up different threads on every timer
event (cond_wait inside the thread and cond_signal in the timer func).

Isn't there another (POSIX) possibility to implement periodic tasks.

thanks

jan

Mario Charest

Re: How a periodic task is handled?

Post by Mario Charest » Fri Oct 31, 2003 1:22 pm

"Jan Rüdiger" <ruediger@uni-mannheim.de> wrote in message
news:bntd9l$k26$1@inn.qnx.com...
Hi

We are sitting here on the same problem. Timer works great if you have
only a few. But we have one Programm starting a lot of thread. Each
thread gets a different priority and some a fifo. Our Problem now that
we don'T know under which priority the timers run. Do they have the same
as the father prog? also the don't show up in pidin?
Thread priority doesn't matter it's the priority of the pulse generated by
the timer that matters as the thread will change it's priority to that of
the pulse

Of course if a thread is handling a timer event and another timer event
comes in, the first even will need to be handle before the next one is
handle. If the second even is of higher priority the handling of the first
event will be process at the priority of the second event.

When you say "priority timers run", that doesn't mean anything timers don't
run, they are handle by the kernel at each tick and it's what kind of event
that is generated by the timer that's subjected to scheduling rules. My
understanding is the kernel process all timer events in one loop and then
apply standard scheduling rules.
Our Workaround are timers that wake up different threads on every timer
event (cond_wait inside the thread and cond_signal in the timer func).
Why the cond stuff? I'm not following
Isn't there another (POSIX) possibility to implement periodic tasks.

thanks

jan

Rennie Allen

Re: How a periodic task is handled?

Post by Rennie Allen » Fri Oct 31, 2003 4:10 pm

Mario Charest wrote:
When you say "priority timers run", that doesn't mean anything timers don't
run, they are handle by the kernel at each tick and it's what kind of event
that is generated by the timer that's subjected to scheduling rules. My
understanding is the kernel process all timer events in one loop and then
apply standard scheduling rules.
Since Rob opened up the gates for pendatics :-)

Timers do "run" (by run I mean that they transition through different states
as a function of temporal locale - the same as a program does); and yes, they
are handled by the kernel at each tick, but so are scheduling decisions for
threads (which I am sure you won't argue don't run). The fact that timers
code is "built-in" to the kernel, rather than user supplied, doesn't mean
they don't "run" (any more than it would mean that the idle thread doesn't
run).

Jan Rüdiger

Re: How a periodic task is handled?

Post by Jan Rüdiger » Mon Nov 03, 2003 10:40 am

Mario Charest wrote:
"Jan Rüdiger" <ruediger@uni-mannheim.de> wrote in message
news:bntd9l$k26$1@inn.qnx.com...

Thread priority doesn't matter it's the priority of the pulse generated by
the timer that matters as the thread will change it's priority to that of
the pulse
We are not using pulses, because MsgSend/Msgreceive is not POSIX. We are
just using timers.
Of course if a thread is handling a timer event and another timer event
comes in, the first even will need to be handle before the next one is
handle. If the second even is of higher priority the handling of the first
event will be process at the priority of the second event.

When you say "priority timers run", that doesn't mean anything timers don't
run, they are handle by the kernel at each tick and it's what kind of event
that is generated by the timer that's subjected to scheduling rules. My
understanding is the kernel process all timer events in one loop and then
apply standard scheduling rules.


Why the cond stuff? I'm not following
Because we have different timers with different expirations/priorities.
At the moment we are using timers to just wake up different threads. The
advantage for us is, that in case of a thread we can adopt priority and
scheduliung to our needs. Another advantage is, since we don't know how
timers are scheduled, that the code inside the timers is very short and
so a fast running timer can easily interrupt another timer.
The third point for us is, that we want to be "as POSIX" as possible.

Two Problems remain for us. First we don't know how the timers are
handled by the Kernel? can a low priority (if they have a priority)
timer be interrupted by a higher one?
Is there a better (POSIX) solution for our problem?

thanks

jan rüdiger
jan



Post Reply

Return to “qdn.public.devtools”