[MPlayer-dev-eng] threaded cache

[Reimar Döffinger]

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.