[MPlayer-dev-eng] threaded cache

[Reimar Döffinger]

On Sun, Nov 27, 2011 at 04:56:31PM +0100, Reimar Döffinger wrote:
> On Sun, Nov 27, 2011 at 04:15:20PM +0100, Reimar Döffinger wrote:
> > On Sun, Nov 27, 2011 at 04:12:00PM +0100, Reimar Döffinger wrote:
> > > On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote:
> > > > +#if defined(PTHREAD_CACHE)
> > > > +            pthread_mutex_lock(&s->go_ahead_mutex);
> > > > +            clock_gettime(CLOCK_REALTIME, &ts);
> > > > +            ts.tv_nsec += sleep_time*1000;
> > > > +            pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts);
> > > 
> > > Operating systems do not have to provide (and some, including older
> > > Linux do not) provide a monotonous clock.
> > > I very strongly dislike usage of such inherently unportable stuff
> > > (I blame pthreads for relying on absolute timeouts (which is reasonable)
> > > without providing for a time source).
> > 
> > Ha, they actually did think of that:
> > pthread_get_expiration_np
> > Except for "Note: This function is not portable." *facepalm* WTF is the
> > point of it then? Hey, we saw there's a portability issue with our API.
> > Let's add a non-portable API to solve it!
> 
> I read about everything I could find about it.
> My conclusion is that pthread_cond_timedwait is full of race conditions,
> even on systems that _do_ support a monotonic clock that it is
> completely unusable if you actually need to rely on the timeout.
> Or to write it in bold:
> THERE IS NO WAY TO USE pthread_cond_timedwait CORRECTLY.

Sorry for the mail SPAM.
Using pthread_condattr_setclock to select the monotonic clock might
actually work.
However note that glibc pthreads depending on which kernel it was
compiled against might silently ignore it by what I can tell -
in which case using it you get guaranteed breakage instead of a
race condition.
Even ignoring that you are deep, deep into non-portable territory
when using CLOCK_MONOTONIC.
I also admit that MPlayer currently won't behave fully correctly with
system clock changes anyway, however I think it at least will not hang
completely (which maybe it would when pthread_cond_timedwait does not
work correctly here - not sure, the main thread might just end up waking
it up as soon as the user attempts a seek operation or something, not
sure it always will).