Date: Fri, 12 Oct 2007 14:56:52 +0000 (UTC) From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/usr.bin/lockf lockf.1 lockf.c Message-ID: <200710121456.l9CEuqhK052668@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
csjp 2007-10-12 14:56:52 UTC FreeBSD src repository Modified files: usr.bin/lockf lockf.1 lockf.c Log: Revision 1.12 of lockf.c fixed a "thundering herd" scenario when the lock experienced contention a number of processes would race to acquire lock when it was released. This problem resulted in a lot of CPU load as well as locks being picked up out of order. Unfortunately, a regression snuck in which allowed multiple threads to pickup the same lock when -k was not used. This could occur when multiple processes open a file descriptor to inode X (one process will be blocked) and the file is unlinked on unlock (thereby removing the directory entry allow another process to create a new directory entry for the same file name and lock it). This changes restores the old algorithm of: wait for the lock, then acquire lock when we want to unlink the file on exit (specifically when -k is not used) and keeps the new algorithm for when -k is used, which yields fairness and improved performance. Also, update the man page to inform users that if lockf(1) is being used to facilitate concurrency between a number of processes, it is recommended that -k be used to reduce CPU load and yeld fairness with regard to lock ordering. Collaborated with: jdp PR: bin/114341 PR: bin/116543 PR: bin/111101 MFC after: 1 week Revision Changes Path 1.19 +13 -1 src/usr.bin/lockf/lockf.1 1.17 +59 -10 src/usr.bin/lockf/lockf.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710121456.l9CEuqhK052668>