[etherlab-users] Multi-threading and calling the cyclic task issue

[Dusty Clark]

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 <mulligan252 at 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 <
> gavinl at 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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160128/79ad4af1/attachment-0004.htm>