Hi,
On Thu, Feb 25, 2016 at 9:18 PM, Wan-Teh Chang <[email protected]
> wrote:
> Although not documented, |state| is guarded by either |mutex| or
> |progress_mutex|. In several places |state| is read without mutex
> protection, often as a double-checked locking style performance
> optimization. Fix the data races by reading |state| under mutex
> protection.
>
[..]
> - if (p->state != STATE_INPUT_READY) {
> - pthread_mutex_lock(&p->progress_mutex);
> - while (p->state != STATE_INPUT_READY)
> - pthread_cond_wait(&p->output_cond, &p->progress_mutex);
> - pthread_mutex_unlock(&p->progress_mutex);
> - }
> + pthread_mutex_lock(&p->progress_mutex);
> + while (p->state != STATE_INPUT_READY)
> + pthread_cond_wait(&p->output_cond, &p->progress_mutex);
> + pthread_mutex_unlock(&p->progress_mutex);
This will be slower, right? Is this an actual issue? Like, can you point to
cases like [1] (i.e. a real-world race condition with real-world
consequences) that were fixed with your patch?
Ronald
https://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
