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
<[email protected]> 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
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
