<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>That´s completely missing the point. An atomic variable would have the exact same fundamental timing issues as a variable with a mutex.</p>
</blockquote>
<p>Hi Rémi, are you really sure. See here -> https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/</p>
</blockquote>
<p>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”.</p>
<p>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.</p>