[pulseaudio-discuss] Making locking nicer for NFS

[David Henningsson]

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
> <mailto: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