[vlc-devel] [RFC-PATCH 04/12] core: introduce input_Decoder{Set, Get}PrerollEnd

[Filip Roséen]

> >That´s completely missing the point. An atomic variable would have the exact 
> >same fundamental timing issues as a variable with a mutex.
> 
> Hi Rémi,
> are you really sure.
> See here -> https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/

It is not the integrity of the variable itself that Remi was referring to, but
the fact that writes to the variable (not from within the decoder) could happen
inbetween work where the decoder assumes that "hey, I am the one controlling the
preroll, so I can overwrite this value with VLC_TS_INVALID if I want to".

The problem stated above could be fixed by an atomic_compare_exchange, where the
decoder does not unconditionally write VLC_TS_INVALID to denote the end of the
preroll, but instead only does so if the preroll-end timestamp is what it
expects it to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160511/3101b503/attachment.html>