[vdr] Re: usleep question.

[Clemens Kirchgatterer <clemens@thf.ath.cx>]

Andreas Schultz <aschultz@cs.uni-magdeburg.de> wrote:


> > > This explains the lookup's when running under real-time
> > > scheduling. The scheduler will not allow other process to run,
> > > therefore completly blocking out all other processes.
> >
> > That also suggests that it would be safer to use
> > usleep(10000) instead of usleep(1), doesn't it?
> 
> to me, it suggest not to use usleep() at all. Waiting for some other
> task to complete something should be done through the mechanisms
> designed for that (mutex, condition variable, semaphore).

YES! i have done it both ways. waiting for a variable in an usleeped
polling loop is ok, as long latency does not matter and you do not rely
on a certain state after one iteration (using no loop at all). i ended
up, writing my own signal class for this kinds of multi threaded event
triggering. using a conditional signal decreases latency dramatically,
as the kernel reorders the processes in the sheduler task list to
benefit for the waiting thread.

if someone is intrested in the code ....

best regards ...
clemens