<div dir="ltr">Hi Remi,<div><br></div><div>Volatile (threading is irrelevant here) will stop a given (eg "chunk->next") from being stored in a register for future accesses.</div><div><br></div><div>Thus, let us look at the following simple case (though this is not precisely the code),</div>
<div><br></div><div>while(chunk->next);</div><div><br></div><div>A compiler can reasonably look at the above, decide that chunk->next cannot change, stash it in a register and thus infinitely loop if it is not null.  Lets call this execution flow thread 1.</div>
<div><br></div><div>Let us assume that a second thread t2 changes chunk->next.  Since t1 is storing what it believes to be chunk->next in a register (and not updating it from the actual memory location), t1 will get stuck in whatever state it was in in the first place.</div>
<div><br></div><div>I only added the volatile after I ran into exactly the aforementioned phenomenon.</div><div><br></div><div>Please tell me what you disagree with above.</div><div><br></div><div>--Jonathan</div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 10:48 PM, Jonathan Thambidurai <span dir="ltr"><<a href="mailto:jonathan@fastly.com" target="_blank">jonathan@fastly.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Apologies,<div><br></div><div>Its was definitely sent to the correct address.  Resending here in its entirety:</div>
<div class=""><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">This patch should take care of the above concerns; it also fixes some bugs.</span><div style="font-family:arial,sans-serif;font-size:13px">

<br></div><div style="font-family:arial,sans-serif;font-size:13px">The following is noted:</div><div style="font-family:arial,sans-serif;font-size:13px">-volatile was necessary because the compiler was optimizing out some memory accesses that were necessary because two threads were (safely) operating on the same data structure.  I've reshuffled some code since that time, so it may not still occur, but shouldn't hurt.</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">-I put the data definitions in a separate header file because I'm likely to add some functionality (bitrate changing, seeking, etc), that may require adding more .c files to prevent things from getting out of hand.  A separate header is a step in that direction.</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">-The ultra-large values for segment runs and fragments runs are what I imagine are the reasonable worst cases.  The spec. defines nothing in terms of hard limits here.  In fact, its quite vague.</div>

<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">--Jonathan</div></div><div><br></div></div></div><div class="gmail_extra"><div><div class="h5"><br>
<br><div class="gmail_quote">
On Wed, May 28, 2014 at 10:43 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Le 2014-05-29 13:27, Jonathan Thambidurai a écrit :<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Did you miss ny above explanation about volatile? Or did you find it<br>
insufficient/unconvincing?<br>
</blockquote>
<br></div>
I cannot find any explanation in the archive...<br>
<a href="https://mailman.videolan.org/pipermail/vlc-devel/2014-May/thread.html" target="_blank">https://mailman.videolan.org/<u></u>pipermail/vlc-devel/2014-May/<u></u>thread.html</a><span><font color="#888888"><br>

<br>
-- <br>
Rémi Denis-Courmont<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <br><div dir="ltr"><img src="https://www.fastly.com/sites/default/files/logo_email_siganture-01.png" width="96" height="44"><br>
<div><br></div><div><b>Jonathan Thambidurai</b> | Engineer | <a href="tel:650%20440%203421" value="+16504403421" target="_blank">650 440 3421</a></div>
<div><a href="http://fastly.com" target="_blank">fastly.com</a> | <a href="https://twitter.com/fastly" target="_blank">@fastly</a> | <a href="http://www.linkedin.com/company/fastly" target="_blank">LinkedIn</a><br></div>
</div>

</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><img src="https://www.fastly.com/sites/default/files/logo_email_siganture-01.png" width="96" height="44"><br><div><br></div><div><b>Jonathan Thambidurai</b> | Engineer | 650 440 3421</div>
<div><a href="http://fastly.com" target="_blank">fastly.com</a> | <a href="https://twitter.com/fastly" target="_blank">@fastly</a> | <a href="http://www.linkedin.com/company/fastly" target="_blank">LinkedIn</a><br></div></div>

</div>