<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 26.03.2013 um 22:15 schrieb Rémi Denis-Courmont <<a href="mailto:remi@remlab.net">remi@remlab.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">Le mardi 26 mars 2013 22:58:25, David Fuhrmann a écrit :<br><blockquote type="cite">It covers the fill state of the buffer. And I am assume that loading a 32<br>bit integer from RAM can be also considered as atomic (at least in the<br>sense that the result is not inconsistent).<br></blockquote><br>To disable compiler optimization you would need to add the volatile keyword at <br>the very least. In other words, no. But it's irrelevant anyway.<br></blockquote><div><br></div><div>volatile is already used. And this is relevant for me because this assumption is made in several places in the code.</div><br><blockquote type="cite"><br><blockquote type="cite">This is why I thought that if we use this result (stored into in another<br>variable), it will be ok?<br><br><blockquote type="cite"><blockquote type="cite">For this scenario I assumed that these will suffice for<br>proper thread synchronization.<br></blockquote><br>Locking the mutex makes no sense if you don't change state. You could<br>remove the locking and unlocking calls to the same effect.<br><br>Then it would be obvious that scheduling predictability was missing.<br>Hence I strongly suspect that waiting can still deadlock with<br>unfortunate timings. In particular, I do not see what synchronization<br>directive prevents the render thread from signalling the condition<br>variable in the short time window after the audio thread checks the<br>buffer tial but before it starts waiting in the condition.<br></blockquote><br>But If I understand right, this is *exactly* the scenario where a mutex<br>lock around vlc_cond_signal makes sense!?<br></blockquote><br><blockquote type="cite">In this short time you are<br>mentioning (between getting the size of the buffer and calling<br>vlc_cond_wait again on the thread which calls flush) the mutex is locked.<br></blockquote><br>The whole point is that this is the same problem and locking the mutex changes <br>nothing.</blockquote><div><br></div><div>I gave an example where locking the mutex around vlc_cond_signal *will* change something, in my eyes. Just saying the opposite is no helpful argument for me.</div><br><blockquote type="cite"> It just moves the race to the time between moving the tail and <br>locking the mutex, instead of the time between moving the tail and signaling <br>the variable.<br></blockquote><div><br></div></div>This is another scenario. Now you are mentioning the time between consuming the buffer, and calling pthread_cond_signal.<div>In this scenario it can be even assumed that the buffer is not refilling anymore (if Flush was already called). So I still fail to find a schedule for calls to Flush at the one thread, and calls to RenderCallbackAnalog on the other thread, where a deadlock might occur. This is why I asked if you have a concrete example (schedule).</div><div><br></div><div>I admit that current checking for the buffer fill count might be a problem as it uses the return value. But if I change it to something like</div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(49, 89, 93); ">vlc_mutex_lock<span style="color: #000000">(&p_sys-></span><span style="color: #4f8187">lock</span><span style="color: #000000">);</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "> <span style="color: #31595d">TPCircularBufferTail</span>(&p_sys-><span style="color: #4f8187">circular_buffer</span>, &availableBytes);</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "> <span style="color: #bb2ca2">while</span> (availableBytes > 0) {</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "> <span style="color: #31595d">vlc_cond_wait</span>(&p_sys-><span style="color: #4f8187">cond</span>, &p_sys-><span style="color: #4f8187">lock</span>);</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "> <span style="color: #31595d">TPCircularBufferTail</span>(&p_sys-><span style="color: #4f8187">circular_buffer</span>, &availableBytes);</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "> }</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="color: #31595d">vlc_mutex_unlock</span>(&p_sys-><span style="color: #4f8187">lock</span>);</div></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; "><br></span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; ">we come back to my question above in how this readout of the buffer count (availableBytes) can be considered atomic.</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; ">(Or what might be problematic if it is not atomic? As availableBytes is only decreasing, the while loop will end in any case, at some time.)</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; "><br></span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; ">Best regards,</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo; "><span style="font-family: Helvetica; font-size: medium; ">David</span></div></body></html>