Results 1 to 4 of 4
Hi,
I want to create 2 timers in my program using timer_create POSIX call.
I want both the timers to be CLOCK_REALTIME type.
When I create 1 such timer then ...
- 02-22-2010 #1Just Joined!
- Join Date
- Feb 2010
- Posts
- 2
using timer_create to create Clock_realtime
Hi,
I want to create 2 timers in my program using timer_create POSIX call.
I want both the timers to be CLOCK_REALTIME type.
When I create 1 such timer then it works fine and does raise a signal
which I catch to perform a task periodically. But when I do the same
to create another such timer then I receive a segmentation fault.
Can i not create 2 CLOCK_REALTIME timers in one program. I searched
a lot but no result.
- 02-22-2010 #2Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
I'm not sure you can create more than one realtime clock per process. I also haven't found anything in the documentation or quick search to that effect; however, you should be able to fork your process before setting the timer and set the timer in both parent and child processes, then the child signaling the parent when the timer expires.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 02-24-2010 #3Just Joined!
- Join Date
- Feb 2010
- Posts
- 2
Actually i have to call a function every 'n' seconds to perform a task without letting the program halt, like it would do if i use sleep or nanosleep.
Thus i thought to use 'timer' as it would raise signals every 'n' seconds which i would catch to call the function repetitively using 'sigaction'.
Can i use any other better method here??? apart from this.
- 02-24-2010 #4Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,974
I used to do something like this for a realtime scheduler. If you have multiple "tasks" to accomplish and they are scheduled at different times, then you need some sort of structure that you can form into a linked list so that as each scheduled task is ready to run, you can pull it off, place the structure in an accessible variable from outside the interrupt handler, then you return from the interrupt handler where your code can dispatch the task (probably in a new thread) and reset the timer for the next task to run. If the task that has just been dispatched needs to be rescheduled, then you can place the timer information in the structure and relink it back to the end of the list, getting in effect a "round-robin" type of scheduler. Of course there are a lot of other little details to deal with, such as recomputing the expiration of the next timer event before you set it. In any case, I used this type of method to balance the processing load amongst a number of Sparc processors on a network of Solaris and HPUX systems a number of years ago for performance analysis of large-scale distributed systems.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!


Reply With Quote