Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger) 10.01.05 17:29
cCondWait::SleepMs() is just used as a replacement for the previous
usleep(), since there was a lot of ado about usleep() not giving up
its time slice etc.
Hm, i see. I was not aware of the history.
There's no need for cCondWait::SleepMs() to return anything.
If you can suggest a better way of just waiting some milliseconds
while giving up the time slice, please advise.
No, I would ask instead:
Why is it required to give up the slice by waiting a fixed time?
Is there really nothing to "wait at"?
You might need some interthread "communication".
I assume that "sleep" stem from pre-thread time of VDR?
Of cause a
while (flag not set by other thread){
give the other threads time to run by sleeping
}
is easy to implement, and "worgs",
but causes a lot of CPU load or wastes time.
For example "conditions" releases the slice too and the
way of communication is clear and there is no (big) trouble
with "mutex"-locking.
Too the waiting thread will resume immediately its work,
not 999ns or maybe 2999ns later, causing other threads to leave
their sleep, wasting further cycles to re-enter the sleep state.
As the operations are really "synchronized" (with "sleeps" you will
have some time jitter) the behaviour if the app is more determistic.
It's more likely to have "works/does not work" and avoids the ugly
and hard to debug third digital state: "does sometimes not work".
"Polling" should be avoided where ever possible.
But, Ok, that would be lot of work to implement,
"only" to lower the load of 6% per process to (maybe) 0,01%.
Maybe the "cCondWait:Signal()" could be used more often
so "one day" the timeout may be set to eternity.
But: How can the other threads know where to signal?