[pulseaudio-discuss] Pulse-cookie locking in NFS causes 30 second delays

[Colin Guthrie]

'Twas brillig, and David Henningsson at 19/08/11 09:21 did gyre and gimble:
> Hi,
> 
> I came across this bug:
> 
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269
> 
> Which claims the following (and also offers a patch [1] to fix it). I
> don't know much about file locking or NFS, but maybe someone here knows
> more than I here.
> 
> Quoting the bug:
> 
> Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is
> manipulated by the code in src/pulsecore/authkey.c. Currently it does
> this to read the key:
> 1) Open the file
> 2) Acquire a write-lock for the file.
> 3) Read the file.
> 4) If the file is not a good cookie, generate a new cookie and write it
> to the file.
> 5) Close the file.
> 
> If more than one thread is opening the cookie at once, then there is
> contention at step (2) which is rarely necessary. Instead, step (2)
> should acquire only a read-lock, and then step (4) should promote that
> to a write-lock before writing the file.
> 
> This is particularly bad in the case where the .pulse-cookie file is on
> NFS. In that case, the lock contention forces a thirty-second backoff
> from whichever thread gets there second.
> 
> I am happy to work with y'all in engineering a patch for this. It
> requires obviously a change to src/pulsecore/authkey.c, and a
> corresponding one in src/pulsecore/core-util.c where the actual lock
> syscall occurs.
> 
> The following script (if ~ is in NFS) will demonstrate the problem. The
> two pactl processes both try to acquire the lock on the file
> simultaneously, and whichever one loses will take thirty seconds before
> it wins, because of the needless contention (and the unfortunate facts
> of how lockd in NFS works).
> 
> !/bin/bash
> 
> NUM_PROCS=2
> 
> procs=()
> for i in $(seq 1 $NUM_PROCS); do
>   pactl list > /dev/null &
>   procs[$i]=$!
> done
> for i in $(seq 1 $NUM_PROCS); do
>   wait ${procs[$i]}
> done
> 
> 


On first glance, this seems sensible, but I'd like Lennart's comment on
this one as locking is one area I don't feel super confident playing
around with!

Lennart, thoughts? See the link for the proposed patch.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]