I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set up a
one shot timer that sent a pulse when the time was up but I have to wait for
the pulse syncronously so the loop cannot run. Is there an asynchronous
version of a pulse or is it best to check the current time at the end of the
loop and exit if it’s greater than Tmax?
Hi Paul,
The problem is not on the pulse, because a pulse IS asynchronous, but in
the way to receive it, ok?
I think it should be better to start a thread which is dedicated to
receive the pulse and set a flag to break your loop or kill the loop
thread, etc…
But if you really want to stay in the same thread, you can use that:
timer_create()
timer_settime(your_amount_of_time);
while (1){
timer_timeout(CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE,
NULL, NULL, NULL);
if (MsgReceivePulse(chid, &pulse, sizeof(pulse), NULL)
== -1) {
if (errno ! = ETIMEDOUT) {
you should normally check out if it’s you
pulse code!
break;
}
}
…anything you want
}
To call timer_timeout() like that means that you want to pool for the
pulse so, you won’t wait any time in MsgReceive().
regards,
Alain.
Paul Jones a écrit:
I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set up a
one shot timer that sent a pulse when the time was up but I have to wait for
the pulse syncronously so the loop cannot run. Is there an asynchronous
version of a pulse or is it best to check the current time at the end of the
loop and exit if it’s greater than Tmax?
I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set up a
one shot timer that sent a pulse when the time was up but I have to wait for
the pulse syncronously so the loop cannot run. Is there an asynchronous
version of a pulse or is it best to check the current time at the end of the
loop and exit if it’s greater than Tmax?
Why not check the current time? Unless each individual iteration
of the loops takes a long time, and you therefore aren’t getting the
granularity you need, I’d just check the current time.
If you do need to “interrupt” the processing in the middle of the loop, then
much as I hate signals, look at “alarm()”
Cheers,
-RK
\
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set up a
one shot timer that sent a pulse when the time was up but I have to wait for
the pulse syncronously so the loop cannot run. Is there an asynchronous
version of a pulse or is it best to check the current time at the end of the
loop and exit if it’s greater than Tmax?
Why not check the current time? Unless each individual iteration
of the loops takes a long time, and you therefore aren’t getting the
granularity you need, I’d just check the current time.
If you do need to “interrupt” the processing in the middle of the loop, then
much as I hate signals, look at “alarm()” >
I agree with Robert, except, the issue might not just be granularity.
If your loop can block for any reason, and you may want to kill your
loop in the middle of an iteration, then as Robert said, alarm().
Why not check the current time? Unless each individual iteration
of the loops takes a long time, and you therefore aren’t getting the
granularity you need, I’d just check the current time.
I won’t recommend polling time unless loop is long.
Retrieving time could cost; usually it’a syncronous system call,
and needs context switches, which you don’t want in tight loops.
Waiting async signal/pulse should be better.
Ofcourse cost will be minimum if gettimeofday() is implemented by just
reading machine-wide shared memory, which is updated by kernel tick,
but that’s unlikely even in monolithic kernel.
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set
up a
one shot timer that sent a pulse when the time was up but I have to
wait for
the pulse syncronously so the loop cannot run. Is there an
asynchronous
version of a pulse or is it best to check the current time at the end
of the
loop and exit if it’s greater than Tmax?
Why not check the current time? Unless each individual iteration
of the loops takes a long time, and you therefore aren’t getting the
granularity you need, I’d just check the current time.
If you do need to “interrupt” the processing in the middle of the loop,
then
much as I hate signals, look at “alarm()” >
I agree with Robert, except, the issue might not just be granularity.
If your loop can block for any reason, and you may want to kill your
loop in the middle of an iteration, then as Robert said, alarm().
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second
Cheers,
-RK
Paul.
“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b28v4b$hqm$> 5@inn.qnx.com> …
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
I would like to have a loop that exits after a certain amount of time
regardless of how many times the loop has executed. For example:
while(loop_execution_time < Tmax)
{
// Run loop
}
Is there a good way of performing this in QNX? I thought I could set
up a
one shot timer that sent a pulse when the time was up but I have to
wait for
the pulse syncronously so the loop cannot run. Is there an
asynchronous
version of a pulse or is it best to check the current time at the end
of the
loop and exit if it’s greater than Tmax?
Why not check the current time? Unless each individual iteration
of the loops takes a long time, and you therefore aren’t getting the
granularity you need, I’d just check the current time.
If you do need to “interrupt” the processing in the middle of the loop,
then
much as I hate signals, look at “alarm()” >
I agree with Robert, except, the issue might not just be granularity.
If your loop can block for any reason, and you may want to kill your
loop in the middle of an iteration, then as Robert said, alarm().
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse >
Or better yet, if you have the kind of architecture that supports the
RDTSC (Read_CPU_timestamp) instruction, just inline that into your
routine and do he math.
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse >
Or better yet, if you have the kind of architecture that supports the
RDTSC (Read_CPU_timestamp) instruction, just inline that into your
routine and do he math.
Doesn’t work well on SMP :=-0 (processors aren’t synchronized) and more expensive
than checking a global variable.
Awww, I’m just being argumentative (except for the SMP note).
Cheers,
-RK
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Paul Jones <> paul.jones@bnc.ox.ac.uk> > wrote:
Thanks for the replies. To clarify the loop takes approximately 0.5ms and
cannot block, its just number crunching. time() appears to be the best way
to go.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse >
Or better yet, if you have the kind of architecture that supports the
RDTSC (Read_CPU_timestamp) instruction, just inline that into your
routine and do he math.
Doesn’t work well on SMP :=-0 (processors aren’t synchronized) and more expensive
than checking a global variable.
Awww, I’m just being argumentative (except for the SMP note). >
Touche’. I wasn’t thinking of SMP. But why should it be a more
expensive instruction? You’re comparing to a CPU register as opposed to
a mem-compare.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse >
Or better yet, if you have the kind of architecture that supports the
RDTSC (Read_CPU_timestamp) instruction, just inline that into your
routine and do he math.
Doesn’t work well on SMP :=-0 (processors aren’t synchronized) and more expensive
than checking a global variable.
Awww, I’m just being argumentative (except for the SMP note). >
Touche’. I wasn’t thinking of SMP. But why should it be a more
expensive instruction? You’re comparing to a CPU register as opposed to
a mem-compare.
Dunno. Just seems more expensive. 64-bit operation? Comparison against
a specific value as opposed to zero/non-zero? I’m out of steam on this
topic Maybe I can “tag out” to someone who knows the super-low-level
details of x86 architecture…
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
If that’s the case, then you can check the time() only once ever
several hundred iterations to increase efficiency – time() gives you
one second resolution, this 1/0.5ms = 2000 iterations per second – there’s
no need to check the time() 2000 times per second >
True. But if you need finer resolution, you can call clock_gettime().
It has nanosecond granularity and ticksize accuracy. It is the call
undernieth time() anyway. So it’s actually less overhead.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer pulse >
Or better yet, if you have the kind of architecture that supports the
RDTSC (Read_CPU_timestamp) instruction, just inline that into your
routine and do he math.
Doesn’t work well on SMP :=-0 (processors aren’t synchronized) and more expensive
than checking a global variable.
Awww, I’m just being argumentative (except for the SMP note). >
Touche’. I wasn’t thinking of SMP. But why should it be a more
expensive instruction? You’re comparing to a CPU register as opposed to
a mem-compare.
Dunno. Just seems more expensive. 64-bit operation? Comparison against
a specific value as opposed to zero/non-zero? I’m out of steam on this
topic > > Maybe I can “tag out” to someone who knows the super-low-level
details of x86 architecture… >
On SMP we have to lock the thread to a single CPU - Bad thing ™. As for comparing to a CPU
register… you said it by yourself “RDTSC - Read_CPU_timestamp”. In the best case (TSD flag clear
or we at priviledge level 0 ) we just read timestamp into EDX:EAX… than we have to compare this
uint64 with memory… In QNXRTP it would be better to use ClockCycles() - the same result but
without headache
From other hand, on x86 it’s also possible to use hardware clock (RTC) and interrupt on 8th line
will kick us up with predefined interval and quite regular
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer
pulse >
Or calls nanosleep(). Way more portable than the pulse!
It’s useless if you have to wait for 500 microseconds because of
nanosleep is an active waiting loop so it will take 500 microsecond of
CPU time at its priority level.
I think that’s nanospin you are thinking of Armin
Cheers,
-RK
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
A more CISC/RubeGoldberg solution would be to have a global variable
that’s checked by the while() and gets set by a thread that gets a timer
pulse >
Or calls nanosleep(). Way more portable than the pulse!
It’s useless if you have to wait for 500 microseconds because of
nanosleep is an active waiting loop so it will take 500 microsecond of
CPU time at its priority level.
