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

David Henningsson david.henningsson at canonical.com
Fri Aug 19 01:21:56 PDT 2011


I came across this bug:


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).



for i in $(seq 1 $NUM_PROCS); do
   pactl list > /dev/null &
for i in $(seq 1 $NUM_PROCS); do
   wait ${procs[$i]}

David Henningsson, Canonical Ltd.

[1] https://launchpadlibrarian.net/77550336/use-read-locks

More information about the pulseaudio-discuss mailing list