[pulseaudio-discuss] Making locking nicer for NFS

[Thomas Bushnell, BSG]

This method also has the advantage of not relying on lock promotion
semantics, which (apparently) will make the Windoze version easier.

Thomas

On Thu, Aug 25, 2011 at 10:30 AM, David Henningsson <
david.henningsson at canonical.com> wrote:

> On 08/21/2011 04:38 PM, Thomas Bushnell, BSG wrote:
>
>> 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.
>>
>
> Would a good handling of this be:
>
> 1) Open the cookie read-only
> 2) read the cookie
> 3) close file
> 4) if we have a correct cookie, do nothing more
> 5) if we have the wrong cookie, do the old handling unchanged: open with
> write lock, check the contents (again), and write if something is (still)
> wrong.
>
>
>> On Aug 21, 2011 4:46 AM, "David Henningsson"
>> <david.henningsson at canonical.**com <david.henningsson at canonical.com>
>> <mailto:david.henningsson@**canonical.com<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
>>
>
>
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110825/1b066e55/attachment-0001.htm>