[pulseaudio-discuss] Making locking nicer for NFS

[Thomas Bushnell, BSG]

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