<p>Whoops. They need to repeat the read after obtaining the write lock and only update the file if the contents are still bad in that case.</p>
<div class="gmail_quote">On Aug 21, 2011 4:46 AM, &quot;David Henningsson&quot; &lt;<a href="mailto:david.henningsson@canonical.com">david.henningsson@canonical.com</a>&gt; wrote:<br type="attribution">&gt; On 08/19/2011 08:14 PM, Thomas Bushnell, BSG wrote:<br>
&gt;&gt; Sorry for breaking the threading, but I only just subscribed to the list<br>&gt;&gt; so I can&#39;t reply properly.<br>&gt;&gt;<br>&gt;&gt; I&#39;m the origin of the patch recently posted by David Henningsson which<br>
&gt;&gt; alters the way locking works. Maarten Bosmans had some questions I&#39;d<br>&gt;&gt; like to address.<br>&gt;&gt;<br>&gt;&gt; The confusing formatting of the diff in core-util.c is just unidiff<br>&gt;&gt; being clever. Basically I created a new function to wrap around fcntl to<br>
&gt;&gt; share the common code between pa_lock_fd and pa_read_lock_fd.<br>&gt;&gt;<br>&gt;&gt; I have no objection of course to simply defining it unconditionally and<br>&gt;&gt; using it always. I do not know Windows, so I was trying to make the<br>
&gt;&gt; minimally disruptive change. I didn&#39;t know that Windows has read locks.<br>&gt;&gt;<br>&gt;&gt; In Unix, promoting a read lock to a write lock converts the lock--it<br>&gt;&gt; does not add another lock--without releasing the readlock in the middle.<br>
&gt;&gt;<br>&gt;&gt; I am not wedded at all to the specific details of what the generic<br>&gt;&gt; functions in core-util.c do.<br>&gt;&gt;<br>&gt;&gt; The root issue is as David Henningsson explained. By using an exclusive<br>
&gt;&gt; lock, pulseaudio creates an unnecessary contention in reading the<br>&gt;&gt; .pulse-cookie file, and because of the less-than-ideal (but quite<br>&gt;&gt; unchangeable) behavior of NFSv3, this forces a thirty-second delay<br>
&gt;&gt; anytime two pulse clients try to read the cookie at the same time.<br>&gt;&gt; Switching to a read lock for the read, and only using an exclusive lock<br>&gt;&gt; when the cookie needs to be written (a much rarer operation), avoids<br>
&gt;&gt; this problem entirely.<br>&gt; <br>&gt; Hi Thomas and thanks for coming here!<br>&gt; <br>&gt; I have a question about the proposed handling. Assume that the cookie is <br>&gt; wrong, and that two clients both find that out in parallel. Then they <br>
&gt; both want to promote their read lock to a write lock. What will happen <br>&gt; in that case?<br>&gt; <br>&gt; -- <br>&gt; David Henningsson, Canonical Ltd.<br>&gt; <a href="http://launchpad.net/~diwic">http://launchpad.net/~diwic</a><br>
</div>