D V wrote:
> Hi Charlie!
>
> Thanks for the answer. Your suggestion could be right, because in the
> serial communication thread I use signal handler to catch the incoming
> data from device. But I don't understand why this action wakes up the
> other thread earlier from usleep? And how can I eliminate this? I have
> no error, so I can't check the error code you've mentioned. do you think
> the nanosleep could be better in this case?
$ man 3 usleep
...
The interaction of this function with the SIGALRM signal,
and with
other timer functions such as alarm(), sleep(),
nanosleep(),
setitimer(), timer_create( ), timer_delete( ),
timer_getoverrun( ),
timer_gettime( ), timer_settime( ), ualarm() is unspecified.
...
This simply means that you can't use sleep, usleep in a multi-threaded
context or you have to make sure there's only one and only thread at a
time that use SIGALRM.
Better use clock_nanosleep, use it with CLOCK_REALTIME if you are
waiting for a date/time, use it with CLOCK_MONOTONIC if you want to
wait an amount of time.
I don't know about you're application, but you can use read() in
blocking mode with a timeout so that you don't need any (u)sleep().
cheers,
Chris
>
> cheers, denx
>
> ------------ --------- --------- --------- --------- --------- -
> *From:* charliem_1216 <charliem_1216@ yahoo.com>
> *To:* .com
> *Sent:* Monday, 23 March, 2009 21:05:30
> *Subject:* [ts-7000] Re: Fast usleep
>
> Hi --
>
> --- In .com <mailto:ts-7000% 40yahoogroups. com>,
> "denx_ts" <> wrote:
> >
> > Hi All!
> >
> > I'm developing a complex system based on TS-7250 SBC. The program is
> written in gnu c (by myself). I have 5 threads in the system and I
> recognize a strange influence between thees. When my serial
> communication thread works - I mean it communicates with an external
> peripheral - the usleep() function getting extremely fast in another
> (the main) thread. I know the resolution of the usleep() is 10 ms, but I
> use it with 2.0-5.0 sec timings, but more precisely than a sec.
> >
> > The strangest part of the situation is the faster behavior of
> usleep() instead of slower. I mean I could imagine that the usleep() is
> getting slower because of high load, but I don't understand how can it
> be faster than normal! (Actually the system isn't at high load, it was
> just an idea.)
> >
> > Any suggestions is appreciated!
>
> On an early wakeup, check the error code to see if it was woken by a
> signal. You could also try nanosleep instead of usleep.
>
> What kernel, and what threading library?
>
> regards, ......... Charlie
> >
> > BR:
> > denx
> >
>
>
>
>
>