[pulseaudio-discuss] Making locking nicer for NFS
david.henningsson at canonical.com
Thu Aug 25 10:30:25 PDT 2011
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
> 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.
More information about the pulseaudio-discuss