[linux-audio-dev] Re: Big Qthread vs. pthread and usleep problem (UPDATE)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: Big Qthread vs. pthread and usleep problem (UPDATE)
From: Danny Shumock (danny_AT_shumock.com)
Date: Fri Nov 30 2001 - 03:42:01 EET


I'm not sure of the particulars of your application but I can provide some
information about usleep, etc. usleep puts the entire process to sleep so
every thread in your application will sleep for the specified interval. This
is usually not what you want in a threaded application. I have in the past
used a real-time timer and signal handler to make a single thread wait for a
specified interval. I put the thread to sleep using pthread_cond_wait and
wait for the condition to be signalled in my signal handler which I set to
the desired time interval. I used setitimer to set the time interval.
Actually I found some code lying around on my computer that does this. You
may be able to use it to gain some more information... I will attach the
relevant files. To use the class (make a thread wait) declare an instance of
CScheduler as a static or global variable and then call the wait method in
the thread that you want to wait. (only one per process will work from what
I can see... if you need more than one thread to wait you'd have to use a
single thread with CScheduler and have that thread signal the other threads
possibly using the attached CEvent class -- wait waits for another thread to
call signal in the CEvent class).

static CScheduler scheduler(10000); // signals every 10 sec

int someThreadFunction()
{
    for(;;) {
        // do something every 10 sec
        scheduler.wait();
    }
}

I hope this helps!

Danny

On Thursday 29 November 2001 07:52 pm, Ivica Bukvic wrote:
> Well, I figured out how to use Qthread, but it seems rather unstable in
> the 2.2 version when it comes to time-critical events, and besides it
> has the same problem with the usleep function. Now the other even more
> funny thing is that the usleep function kept accurate sleep times, but
> somehow they are twice as much, so what I ended up doing is doubling the
> call to update the timer per cycle of the thread, and now the timer is
> back in the working condition. Nonetheless, this is a highly unusual,
> since when I implemented the double call, the gui "laggyness" also
> vanished... go figure :-). If anyone has any idea what the heck is wrong
> with this picture, I'd be greatly thankfull if you shared your knowledge
> regarding this issue wth me! Thanks!
>
> Ivica Bukvic
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<



New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Nov 30 2001 - 03:33:27 EET