I had this 10mS cycle time issue with a multithreaded application awhile back. Turned out the kernel was built with 100Hz base ticks, not 1kHz. Do "cat /proc/timer_list" and have a look at the available timer resolutions on your system, pause() can't work at any lower resolution than the kernel ticks.
On Thu, Jan 28, 2016 at 1:06 AM, Paul Mulligan <mulligan...@yahoo.ie> wrote: > Hi, > > No, the sleeps don't seem to wait more than 10ms. No matter what value I > put there greater than 10 ms, the cyclic_task() is being executed around > 10ms. I have also digital outputs toggling in the cyclic_task() and the > output frequency on oscilloscope is always around 50Hz. This I find quite > strange. I would expect that if I sleep for 1 second, the function would > get called every second. > > The pause() function is the linux function from unistd.h. I used it as it > was in the supplied examples. How could I explicitly block the signal > pause() is waiting for in other threads if I wish to use signals in this > fashion? > > Thanks alot. > > > > > On Wednesday, 27 January 2016, 23:22:02, Gavin Lambert < > gav...@compacsort.com> wrote: > > > On 28 January 2016 08:54, quoth Paul Mulligan: > > > When using multi-threading, such that the function which calls the > > cyclic_task() is running in a separate detached thread from the main > > thread, the pause function blocks forever and a signal is never > > received as below. > [...] > > Also, I tried to use usleep() and sleep() instead of signals to wait for > > the right time to call the cyclic_task(), but the timing is not right. > It > > seems that the sleeps can not wait longer than 10ms. > > > I assume you mean that they can't wait less than 10ms? > > clock_nanosleep should be able to wait a smaller interval (see the dc_user > example), but you also need to set your process priority to one of the > realtime ones (SCHED_FIFO or SCHED_RR) to get lower latency. If you want a > really small latency, then you should use the non-generic network driver > and a PREEMPT_RT kernel. > > If you want to continue using signals, you need to be aware that they're > unthreaded -- a signal will by default wake up any particular thread, not > necessarily the one you are expecting. To fix this and get signals to work > in multithreaded programs, you need to make sure that you explicitly block > the signal in all threads except the one that you're expecting to receive > it. Or alternatively use a more modern timer API that's better suited to > multithreaded applications. I suspect that overall signals or timers will > produce worse performance than using a sleep, however. > > Also, you don't show what the implementation of your pause function is, > but it's likely that unless you're taking care to use atomic variables or > insert the appropriate barriers, the compiler is optimising something away > to turn it into an infinite loop. > > > > > > _______________________________________________ > etherlab-users mailing list > etherlab-users@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-users > >
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
