Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: vdr 1.3.18 cCondWait::SleepMs
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 ------------
Home |
Main Index |
Thread Index