[vdr] Re: vdr 1.3.18 cCondWait::SleepMs

[Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de>]

Mattias.Gronlund@Gronlund.net(Mattias Gronlund)  10.01.05 23:48


>> AFAIK pthread_cond_timedwait unlocks the mutex.
>> Only on timeout it becomes relocked, not on "condition".
>> Why is it unlocked a second time at the end of the function
>> regardless of the state of "signaled" ?
>>

>Hmm, I do thing that you are wrong here, take a look at a more
>descriptive man page fore pthread_cond_wait (they shall both impellent
>the same standard):

>http://docs.hp.com/en/B2355-90695/pthread_cond_wait.3T.html

>The interesting part:
>    When the condition is signaled or the timed wait expires, the
>caller is     unblocked and will reacquire mutex before returning.
>Whether these     functions succeed or fail, mutex will always be
>reacquired before     returning to the caller.

The description i had was not that clear.
See
 
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/users_77.htm

    If the wait is satisfied or times out, or if the thread is
    canceled, before the thread is allowed to continue, the mutex
    is automatically acquired by the calling thread.  If mutex is
    not currently locked, an ENOTLOCKED error results.  You should
    always associate only one mutex with a condition at a time.
    Using two different mutexes with the same condition at the same
    time could lead to unpredictable serialization in your
    application.


"wait" should be read as "condition"...
I thought a satisfied "wait" means: 
the parameter "abstime" is not in the future anymore.
(I could not re-google(c)(r)(tm) the man page the explicit describes that)
                                          

>I have been trying to find a better description of the 2 ms limit in
>nanosleep other then the man-page for nanosleep under BUGS in Fedora
>Core 2.


>    As some applications require much more precise pauses (e.g., in
>order     to  control  some  time-critical hardware), nanosleep is
>also capable of     short high-precision pauses. If the process is
>scheduled under a     real-time policy like SCHED_FIFO or SCHED_RR,
>then pauses of up to 2 ms will be performed as busy waits with
>microsecond precision.

>I have been trying to understand the implementation of nanosleep, but
>gave up when I couldn't even find the code for it in glibc ;).

I think that "up to 2ms" will be sufficient, when
VDR cam afford to release the entire slice.

If one really needs such exact timing because he has a broken
hardware design(*), the "usual way" should be::
get start time
  sleep
get stop ttime
and then calculate the time acutally needed and 
correct the next steps.
Ugly. You don't want to code that but if you are in realtime
you have to and may usuall do teh in the interupt handler, not
the application.

But, as Klaus said:
The CPU slice is given up by intention.
So the actual wait time does not matter.


Multitasking OS gives direct access to the scheduler
to release the unused slice via an API call like "pthread_yield()",

But here is the problem, that VDR can't wait at something useful 
and would eat all CPU cycles by highspeed calling "pthread yield()"...
that's not nice...










(*)
Some of the most dangerous things in the world:
 - A hardware with a software patch.
 - A software programmer with a solder iron.
 





Rainer---<=====>                         Vertraulich
             //
           //                              
         <=====>--------------ocholl, Kiel, Germany ------------