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

[Paul Mulligan]

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.



  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160128/dbf5ccf3/attachment-0003.htm>