[vlc-devel] [PATCH 1/7] playlist/background_worker: introduce background-worker utility
remi at remlab.net
Wed Mar 29 21:26:17 CEST 2017
Le keskiviikkona 29. maaliskuuta 2017, 21.20.02 EEST Filip Roséen a écrit :
> On 2017-03-29 22:03, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 29. maaliskuuta 2017, 20.50.50 EEST Filip Roséen a écrit
> > > > > The thread is per definition not waiting for the conditiona variable
> > > > > at that time, so I cannot see how it would wake itself up.
> > > >
> > > > You are making unwarranted assumptions about condition variables here.
> > >
> > > Assumptions based on specifications, I would however be extremely
> > > interested on implimentations where this "assumption" does not hold
> > > (mostly because a issue should definitely be filed based on such
> > > finding).
> > >
> > > > Been there done that.
> > >
> > > Previous paragraph.
> > There is not much point in discussing if we cannot agree on facts such as
> > the meaning of the specification.
> Opinion acknowledged.
> > Both my experience and my understanding of CV tells me that this patch is
> > factually wrong.
> Given that you say that my assumptions are wrong, the code should be
> easy to break, or there should be a very easy way to demonstrate that
> my assumptions about *condition-variables* are wrong.
> I am happy to take a conforming implementation of the specification as
> an example, so if you could be kind to link me the source of such I
> would happily read it.
I already told you: the thread can end up waking itself up, instead of the
more intuitive behaviour that you expect.
In other words, it is perfectly possible for: lock; signal/broadcast; wait;
unlock; to steal the wake up, when you would expect that it wakes up another
thread (if any is sleeping).
You could argue that many a description of condition variable rules such
behaviour out, or at least seems to. But this happens in real life, and I
cannot say that it would contradict the "original" POSIX definition.
More information about the vlc-devel