[vlc-devel] [PATCH] test: add thread test

[Alexandre Janniaux]

Hi,

After more thought, I don't either.

The cases where the vlc_cond_signal would be «consumed» by the B
critical area are those with `AB` somewhere, so CABD or ABCD.

But, in the first case, the thread will wait on cond, so the
vlc_cond_signal in A is supposed to wake it, except if I don't
understand the following pthread/VLC documentation.

> The pthread_cond_signal() function shall unblock at least one of the
> threads that are blocked on the specified condition variable cond
> (if any threads are blocked on cond).

>  * If any thread is currently waiting on the condition variable, at least one
>  * of those threads will be woken up. Otherwise, this function has no effects.

In the second case, ABC, B might consume the signal from A, but
will then wait on the condition and C will not wait as the state
is already correct.

Regards,
--
Alexandre Janniaux
Videolabs

On Fri, Mar 20, 2020 at 07:28:21PM +0100, Romain Vimont wrote:
> On 3/20/20 6:26 PM, Romain Vimont wrote:
> >
> >
> > On 3/20/20 6:13 PM, Rémi Denis-Courmont wrote:
> > > Le perjantaina 20. maaliskuuta 2020, 18.31.02 EET Alexandre Janniaux
> > > a écrit :
> > > > Hi,
> > > >
> > > > I don't understand the issue,
> > >
> > > The test thread signals itself. Then everything locks dead.
> > >
> >
> > Oh, right. Good catch. I totally missed it.
> >
> > Replacing vlc_cond_signal() by vlc_cond_broadcast() should fix the issue
> > then :)
>
> Sorry, thinking about it, in fact I don't understand the problem.
>
> A thread calling cond_signal() may not "signal itself" since it's not
> cond_wait()ing. :/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel